GitLab CI против Дженкинса

Ответ 1

Это мой опыт:

На моей работе мы управляем нашими репозиториями с помощью GitLab EE, и у нас работает сервер Jenkins (1.6).

В основе они делают почти то же самое. Они будут запускать некоторые сценарии на образе сервера /Docker.

TL; DR;

• Дженкинс легче использовать/изучать, но есть риск стать адским плагином
• Дженкинс имеет графический интерфейс (это может быть предпочтительным, если он должен быть доступен/обслуживаться другими людьми)
• Интеграция с GitLab меньше, чем с GitLab CI
• Дженкинс может быть удален из вашего хранилища

Большинство серверов CI довольно просты (concourse.ci), gitlab-ci, circle-ci, travis-ci, drone.io, gocd и что еще у вас). Они позволяют вам выполнять сценарии shell/bat из определения файла YAML. Дженкинс гораздо более подключаемый, и поставляется с пользовательским интерфейсом. Это может быть как преимуществом, так и недостатком, в зависимости от ваших потребностей.

Jenkins очень легко настраивается благодаря всем доступным плагинам. Недостатком этого является то, что ваш CI-сервер может стать спагетти плагинов.

По моему мнению, связывание и организация заданий в Jenkins намного проще (из-за пользовательского интерфейса), чем через YAML (вызов команд curl). Кроме того, Jenkins поддерживает плагины, которые будут устанавливать определенные двоичные файлы, когда они недоступны на вашем сервере (не знаю об этом для других).

В настоящее время (Jenkins 2 также поддерживает больше "правильного ci" с плагином Jenkinsfile и pipline, который по умолчанию используется в Jenkins 2), но раньше он был менее связан с репозиторием чем то есть GitLab CI.

Использование файлов YAML для определения конвейера сборки (и, в конце концов, запуск чистого shell/bat) более удобен.

Плагины, доступные для Jenkins, позволяют визуализировать все виды отчетов, такие как результаты тестов, покрытие и другие статические анализаторы. Конечно, вы всегда можете написать или использовать инструмент, чтобы сделать это для вас, но это определенно плюс для Дженкинса (особенно для менеджеров, которые склонны слишком высоко ценить эти отчеты).

В последнее время я все больше и больше работаю с GitLab CI. В GitLab они проделывают отличную работу, делая весь опыт увлекательным. Я понимаю, что люди используют Jenkins, но когда у вас запущен и доступен GitLab, действительно легко начать работу с GitLab CI. Не будет ничего, что интегрировалось бы так же гладко, как GitLab CI, даже если они приложили немало усилий для интеграции сторонних разработчиков.

• Их документация поможет вам начать работу в кратчайшие сроки.
• Порог для начала работы очень низкий.
• Обслуживание простое (без плагинов).
• Масштабировать бегунов просто.
• CI полностью часть вашего хранилища.
• Работа Дженкинса/представления могут стать грязными.

Некоторые льготы на момент написания:

• Поддержка только одного файла в версии сообщества. Умножает файлы в корпоративной версии.

Ответ 2

Я согласен с большинством замечаний Рика, но мое мнение о том, что проще, противоположно: GitLab - отличный инструмент для работы.

Большая часть возможностей заключается в автономной и интеграции всего в одном продукте на одной вкладке браузера: от браузера репозитория, доски объявлений или истории сборки до инструментов развертывания и мониторинг.

Я использую его прямо сейчас, чтобы автоматизировать и протестировать, как приложение устанавливается в разных дистрибутивах Linux, и просто быстро настроить (попробуйте открыть сложную конфигурацию заданий Jenkins в Firefox и подождите, пока не адаптивный сценарий и легкость редактирования .gitlab-ci.yml).

Время, затрачиваемое на настройку/масштабирование ведомых устройств, значительно меньше благодаря исполняемым файлам бегуна; плюс тот факт, что на GitLab.com вы получаете вполне приличных и бесплатных общих участников.

Дженкинс чувствует себя более уверенным после нескольких недель работы в GitLab CI, например, дублирование заданий на ветку, установка плагинов для выполнения простых задач, таких как загрузка SCP. Единственный вариант использования, с которым я столкнулся, когда я скучаю по нему, как на сегодняшний день, это когда задействовано более одного хранилища; это нужно еще хорошо понять.

Кстати, в настоящее время я пишу серию о GitLab CI, чтобы продемонстрировать, как легко настроить инфраструктуру CI репозитория с ее помощью. В первой части, опубликованной на прошлой неделе, рассказывается об основах, плюсах и минусах, а также о различиях с другими инструментами: Быстрая и естественная непрерывная интеграция с GitLab CI

Ответ 3

Прежде всего, на сегодняшний день GitLab Community Edition может полностью взаимодействовать с Jenkins. Нет вопросов.

Далее я приведу некоторые отзывы об успешном опыте объединения Jenkins и GitLab CI. Я также буду обсуждать, следует ли вам использовать оба или только один из них, и по какой причине.

Я надеюсь, что это даст вам качественную информацию о ваших собственных проектах.

GitLab CI и сильные стороны Дженкинса

GitLab CI

GitLab CI естественным образом интегрирован в GitLab SCM. Вы можете создавать конвейеры с gitlab-ci.yml файлов gitlab-ci.yml и манипулировать ими через графический интерфейс.

Эти конвейеры в виде кода, очевидно, могут храниться в базе кода, что обеспечивает соблюдение практики "все как код" (доступ, управление версиями, воспроизводимость, возможность повторного использования и т.д.).

GitLab CI - отличный инструмент визуального управления:

• Все члены команд (включая нетехнических) имеют быстрый и легкий доступ к статусу жизненного цикла приложений.
• поэтому его можно использовать как интерактивную и оперативную панель управления выпуском.

Дженкинс

Дженкинс - отличный инструмент для сборки. Это сила во многих плагинах. Особенно мне повезло в использовании интерфейсных плагинов между Jenkins и другими инструментами CI или CD. Это всегда лучший вариант, чем переделывать (возможно, плохо) интерфейс диалога между двумя компонентами.

Конвейер как код также доступен с использованием скриптов groovy.

Совместное использование GitLab CI и Jenkins

Поначалу это может показаться немного избыточным, но объединение GitLab CI и Jenkins довольно мощно.

• GitLab CI управляет конвейерами (цепями, запускает, контролирует...), и можно воспользоваться его графическим интерфейсом, интегрированным в GitLab
• Дженкинс управляет работой и облегчает диалог со сторонними инструментами.

Еще одним преимуществом этой конструкции является слабая связь между инструментами:

• мы могли бы заменить любой из компонентов фабрики сборки без необходимости переделки всего процесса CI/CD
• у нас может быть гетерогенная среда сборки, сочетающая в себе (возможно, несколько) Jenkins, TeamCity, как вы ее называете, и все же иметь единый инструмент мониторинга.

Компромисс

Ну, конечно, за этот дизайн приходится платить: первоначальная настройка громоздка, и вам необходимо иметь минимальный уровень понимания многих инструментов.

По этой причине я не рекомендую такую настройку, если

• у вас есть много сторонних инструментов для работы. Это когда Дженкинс очень пригодится со своими многочисленными плагинами.
• вам приходится иметь дело со сложными приложениями с разнородными технологиями, каждая из которых имеет свою среду сборки, и при этом все еще должен иметь унифицированный интерфейс управления жизненным циклом приложений.

Если вы не находитесь ни в одной из этих ситуаций, вам, вероятно, лучше использовать только одну из двух, но не обе.

Если бы мне пришлось выбрать один

И GitLab CI, и Jenkins имеют свои плюсы и минусы. Оба являются мощными инструментами. Так какой же выбрать?

Ответ 1

Выберите тот, в котором ваша команда (или кто-то из ваших близких) уже обладает определенным опытом.

Ответ 2

Если вы все новичок в технологиях КИ, просто выберите один и приступайте.

• Если вы используете GitLab и разбираетесь во всем, как в коде, имеет смысл выбрать GitLab CI.
• Если вам нужно вести диалог со многими другими инструментами CI/CD или вам нужен графический интерфейс для создания вашей работы, выбирайте Jenkins.

Те из вас, кто использует GitLab и не уверены, что будут продолжать это делать, все же должны помнить, что выбор GitLab CI будет означать уничтожение всех ваших конвейеров CI/CD.

И последнее слово: баланс немного склоняется к Jenkins из-за множества плагинов, но есть вероятность, что GitLab CI быстро заполнит этот пробел.

Ответ 4

Я хотел бы добавить некоторые результаты моего недавнего эксперимента с GitLab CI. Функции, которые пришли с 11.6 и 11.7, просто потрясающие!

В частности, мне нравятся only условия, которые в основном позволяют создавать отдельные конвейеры для merge_request или push (полный список здесь)

Также мне очень нравится отсутствие плагинов. Когда мне нужна более сложная функциональность, я просто пишу собственный образ Docker, который обрабатывает требуемую функциональность (та же концепция, что и в drone.io).

Если вы задаетесь вопросом о СУХОЙ, это абсолютно возможно в наши дни! Вы можете написать свои "шаблоны"

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Поместите их в какой-нибудь публичный репозиторий, включите их в основной конвейер:

include:
  - remote: https://....

И используйте их, чтобы продлить работу:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

Я очень люблю GitLab CI! Да, он (пока) не может рисовать хорошие графики с охватом и так далее, но в целом это действительно отличный инструмент!

Редактировать (2019-02-23): здесь мой пост о вещах, которые я люблю в GitLab CI. Он был написан в 11.7 "эпоху", поэтому, когда вы читаете этот ответ, GitLab CI, вероятно, имеет гораздо больше возможностей.

Edit (2019-07-10): Gitlab CI теперь поддерживает несколько extends, например,

extends:
 - .pieceA
 - .pieceB

Проверьте официальную документацию, чтобы получить больше информации о нескольких расширениях

Ответ 5

если ваши задания по сборке/публикации/развертыванию и тестированию не слишком сложны, то использование gitlab ci имеет естественные преимущества.

Поскольку gitlab-ci.yml присутствует вместе с вашим кодом в каждой ветке, вы можете более эффективно изменять ваши шаги ci/cd, особенно тесты (которые различаются в разных средах).

Например, вы хотите выполнить модульное тестирование для любой регистрации в ветке dev, в то время как вам может потребоваться выполнить полнофункциональное функциональное тестирование в ветки QA и ограниченный тип тестов get на производстве, что может быть легко достигнуто с помощью gitlab ci.

Второе преимущество, помимо отличного пользовательского интерфейса, заключается в том, что он позволяет использовать образы докеров для выполнения любого этапа, сохраняя работоспособность хоста и, следовательно, менее подверженной ошибкам.

Более того, gitlab ci автоматически зарегистрирует вас, и вам не придется управлять мастером jenkins отдельно.