Комментарии 22
Не проще ли завести Gitlab Community Edition? И одним махом решить большую часть проблем DevOps цикла?
Удивительно, что Гитлаба нет в подборке.
Облачная версия очень даже в бесплатном варианте. А подписка стоит не дорого. Для любителей своего хостинга можно поставить к себе. Что еще нужно то?
В комплекте с CI/CD собственно Git, Docker Registry, надстройка для Kubernetes.
Облачная версия очень даже в бесплатном варианте. А подписка стоит не дорого. Для любителей своего хостинга можно поставить к себе. Что еще нужно то?
В комплекте с CI/CD собственно Git, Docker Registry, надстройка для Kubernetes.
Нужен GitFlow. Если мы правильно поняли то, он в гитлабе не возможен?
Честно говоря, не пользовался GiFlow, но вот что нашел: docs.gitlab.com/ee/workflow/gitlab_flow.html
Как не возможен. Я его использую. Это методология управления ветками на базе git. Этот подход не зависит от инструмента. Хоть на TeamCity хоть на Gitlab-CI можно реализовать
Это работает когда у вас в один репозитарий комитят несколько человек и проект из состоит из нескольких репозиториев? Насколько я понял, что в гитлабе один юзер это не юзер как в гите, а дополнительная ветка в репозитории.
На сам деле мы гитлаб пробовали очень давно. Тогда у них небыло gitflow. Скорее всего они что то сделали по этому поводу.
На сам деле мы гитлаб пробовали очень давно. Тогда у них небыло gitflow. Скорее всего они что то сделали по этому поводу.
А как же gitlab-ci?
Gitlab-ci думаю лучший выбор для стартапера
Зашел, чтобы оставить коммент про gitlab-ci. И очень рад, что хабровчане о нем знают и любят. Это действительно великолепный инструмент, который интегрирован в окружение gitlab инфраструктуры. Не уверен можно ли его использовать автономно вне gitlab. Но в любом случае — это отличное решение для небольших команд, кто не хочет сильно заморачиваться на инфраструктуре для CICD, но в тоже время смотрит в будущее своего проекта.
CI/CD использую во всех своих проектах, очень удобно, от 0 до 2 команд на деплой.
На работе в "энтерпрайзе" есть то, что у компании называется CI/CD, но только объяснение "как оно работает" занимает 3 часа, а деплой это ад, вовлекающий 3 докера, практически вручную запускаемые пустыми коммитами в 3 репозитория различных команд, которые не хотят делиться доступами и ходят через PRы при том, что, внезапно выплевываемый результат не деплой, а докер имейдж, который ещё надо развернуть финальной танцей с бубном.
TeamCity забыли
travis?
НЛО прилетело и опубликовало эту надпись здесь
Я по сделал форк репозиториия DeepNude в Gitlab, из статьи на хабре.
Меня заблокировали. Мой аккаунт на Гитлабе. Я начал вести переписку со службой поддержки, меня разлочили, после того, как я согласился сам удалить репоизторий DeepNude.
На GitHub, насколько я знаю, удаляли без согласования с пользователем его личные репозитории c DeepNude.
Этим мне Гитлаб очень приглянулся, что относится к коду пользователей, как к частной собственности, в отличии от Гитхаба.
Jenkins — это Гитхаб, Gitlab CI — это Гитлаб.
К тому же, прекрасная и достаточно доступная документация по Gitlab CI.
Меня заблокировали. Мой аккаунт на Гитлабе. Я начал вести переписку со службой поддержки, меня разлочили, после того, как я согласился сам удалить репоизторий DeepNude.
На GitHub, насколько я знаю, удаляли без согласования с пользователем его личные репозитории c DeepNude.
Этим мне Гитлаб очень приглянулся, что относится к коду пользователей, как к частной собственности, в отличии от Гитхаба.
Jenkins — это Гитхаб, Gitlab CI — это Гитлаб.
К тому же, прекрасная и достаточно доступная документация по Gitlab CI.
НЛО прилетело и опубликовало эту надпись здесь
Это не надо понимать буквально, в лоб.
Имеется ввиду, что большинство пользователей Github выбирают для CI Jenkins, и это такой «стандарт де-факто» на этой платформе.
Имеется ввиду, что большинство пользователей Github выбирают для CI Jenkins, и это такой «стандарт де-факто» на этой платформе.
НЛО прилетело и опубликовало эту надпись здесь
Тут была бы уместна статистическая диаграмма по использованию инструментов для CI,
искал, но нашел другое интересное сравнение
Сравнение инструментов CI/CD
Jenkins
Инструмент CI с открытым исходным кодом, написанный на Java и выпущенный под лицензией MIT. Первоначально являлся частью проекта Hudson, принадлежавшего компании Oracle. Впервые был выпущен 2 февраля 2011 года.
Jenkins представляет из себя достаточно гибкую систему автоматизации задач, связанных с программным обеспечением. Почти весь функционал реализован с помощью плагинов. Хоть это обеспечивает большую гибкость, но в то же время может и являться большим минусом из-за конфликтов с определёнными версиями или остановкой поддержки плагина.
Jenkins pipeline(трубопровод) доступен в виде плагина с 2016 года. Использует язык Groovy, хранимый в удаленном репозитории или же в локальных файлах Jenkins. Основной минус Jenkins заключается в том, что возможность определять groovy-скрипты вне репозитория и использование определенных плагинов для реализации нужного функционала, затрудняют внедрение на других системах Jenkins.
GitLab CI
Инструмент CI, встроенный в GitLab, написанный на на Ruby and Go и выпущены под лицензией MIT. Изначально был выпущен как самостоятельный проект. В дальнейшем интегрирован в основное программное обеспечение GitLab в сентябре 2015 года.
Процесс CI/CD в GitLab CI определяется отдельным файлом в самом хранилище кода с использованием синтаксиса конфигурации YAML. Для выполнения задач используется изолированные виртуальные машины, называемые «GitLab CI runners». Они являются кроссплатформенными.
Главный минус GitLab CI заключается в том, что он привязан к GitLab, что не позволяет использовать другие репозитории. Плюсом является то, что для настройки среды CI/CD не требуется установка и изучение дополнительного инструментария. Нужно всего лишь включить несколько параметров в веб-интерфейсе, зарегистрировать «GitLab CI runner» и добавить файл с синтаксисом конфигурации YAML в репозиторий.
Buildbot
Инструмент CI, написанный на Python и выпускаемый под лицензией GPL. Выпущен в 2003 году в качестве альтернативы проекту Tinderbox в Mozilla. Первоначально являлся инструментом автоматизации тестирования сборки.
Основной минус и одновременно плюс в том, что конфигурация Buildbot полностью написана на Python, что значительно сложнее, чем в других системах, но в то же время это дает больше возможностей для разработки идеального рабочего процесса.
Drone
Современный инструмент CI/CD, основанный на pipeline, написан на Go и выпускаемый под лицензией Apache. Весь рабочий процесс основан на Docker контейнерах. Имеет встроенную поддержку для настройки сертификатов SSL с Let's Encrypt.
Как и в GitLab CI, для конфигурации задач используется синтаксис YAML в репозитории.
Как и в Jenkins, присутствует система плагинов, но представлена она в виде специальных контейнеров Docker, в которых предварительно сконфигурированы задачи для рабочего процесса. Это является несравненным плюсом. Но Docker-контейнеры не всегда удобно использовать на Windows системах.
Пожалуйста, не забудьте правильно оформить цитату:
Бабаев В.С. ИССЛЕДОВАНИЕ СОВРЕМЕННЫХ CI/CD ИНСТРУМЕНТОВ И ВНЕДРЕНИЕ ИХ В КРУПНЫЕ WEB-ПРОЕКТЫ НА ПРИМЕРЕ JENKINS // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. LXXIV междунар. студ. науч.-практ. конф. № 2(73). URL: sibac.info/archive/technic/2(73).pdf (дата обращения: 22.07.2019)
искал, но нашел другое интересное сравнение
Сравнение инструментов CI/CD
Jenkins
Инструмент CI с открытым исходным кодом, написанный на Java и выпущенный под лицензией MIT. Первоначально являлся частью проекта Hudson, принадлежавшего компании Oracle. Впервые был выпущен 2 февраля 2011 года.
Jenkins представляет из себя достаточно гибкую систему автоматизации задач, связанных с программным обеспечением. Почти весь функционал реализован с помощью плагинов. Хоть это обеспечивает большую гибкость, но в то же время может и являться большим минусом из-за конфликтов с определёнными версиями или остановкой поддержки плагина.
Jenkins pipeline(трубопровод) доступен в виде плагина с 2016 года. Использует язык Groovy, хранимый в удаленном репозитории или же в локальных файлах Jenkins. Основной минус Jenkins заключается в том, что возможность определять groovy-скрипты вне репозитория и использование определенных плагинов для реализации нужного функционала, затрудняют внедрение на других системах Jenkins.
GitLab CI
Инструмент CI, встроенный в GitLab, написанный на на Ruby and Go и выпущены под лицензией MIT. Изначально был выпущен как самостоятельный проект. В дальнейшем интегрирован в основное программное обеспечение GitLab в сентябре 2015 года.
Процесс CI/CD в GitLab CI определяется отдельным файлом в самом хранилище кода с использованием синтаксиса конфигурации YAML. Для выполнения задач используется изолированные виртуальные машины, называемые «GitLab CI runners». Они являются кроссплатформенными.
Главный минус GitLab CI заключается в том, что он привязан к GitLab, что не позволяет использовать другие репозитории. Плюсом является то, что для настройки среды CI/CD не требуется установка и изучение дополнительного инструментария. Нужно всего лишь включить несколько параметров в веб-интерфейсе, зарегистрировать «GitLab CI runner» и добавить файл с синтаксисом конфигурации YAML в репозиторий.
Buildbot
Инструмент CI, написанный на Python и выпускаемый под лицензией GPL. Выпущен в 2003 году в качестве альтернативы проекту Tinderbox в Mozilla. Первоначально являлся инструментом автоматизации тестирования сборки.
Основной минус и одновременно плюс в том, что конфигурация Buildbot полностью написана на Python, что значительно сложнее, чем в других системах, но в то же время это дает больше возможностей для разработки идеального рабочего процесса.
Drone
Современный инструмент CI/CD, основанный на pipeline, написан на Go и выпускаемый под лицензией Apache. Весь рабочий процесс основан на Docker контейнерах. Имеет встроенную поддержку для настройки сертификатов SSL с Let's Encrypt.
Как и в GitLab CI, для конфигурации задач используется синтаксис YAML в репозитории.
Как и в Jenkins, присутствует система плагинов, но представлена она в виде специальных контейнеров Docker, в которых предварительно сконфигурированы задачи для рабочего процесса. Это является несравненным плюсом. Но Docker-контейнеры не всегда удобно использовать на Windows системах.
Пожалуйста, не забудьте правильно оформить цитату:
Бабаев В.С. ИССЛЕДОВАНИЕ СОВРЕМЕННЫХ CI/CD ИНСТРУМЕНТОВ И ВНЕДРЕНИЕ ИХ В КРУПНЫЕ WEB-ПРОЕКТЫ НА ПРИМЕРЕ JENKINS // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. LXXIV междунар. студ. науч.-практ. конф. № 2(73). URL: sibac.info/archive/technic/2(73).pdf (дата обращения: 22.07.2019)
Не в обиду автору, но простое перечисление CI\CD и «почему ими пользуются» это скорее для толкового словаря, а не для статьи.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CI\CD для стартапа: какие есть инструменты, и почему ими пользуются не только крупные и известные компании