GitLab CI против Jenkins [закрыто]

В чем разница между Jenkins и другими CI, такими как GitLab CI, drone.io, идущим с дистрибутивом Git. В результате некоторых исследований я мог только прийти к выводу, что версия сообщества GitLab не позволяет добавлять Дженкинса, а корпоративная версия GitLab позволяет. Есть ли другие существенные отличия?

Это мой опыт:

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

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

TL; DR;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GitLab CI и сильные стороны Jenkins

GitLab CI

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

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

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

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

Дженкинс

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

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

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

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

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

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

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

Компромисс

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

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

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

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

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

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

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

Если вас интересует DRY , в наши дни это абсолютно возможно! Вы можете написать свои «шаблоны»,

.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, вероятно, имеет гораздо больше функций.

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

extends:
 - .pieceA
 - .pieceB

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

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

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

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

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

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