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


129

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


5
GitLab также собрал сравнение GitLab CI и Jenkins: about.gitlab.com/comparison/gitlab-vs-jenkins.html
bbodenmiller

Ответы:


123

Это мой опыт:

В моей работе мы управляем нашими репозиториями с помощью 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 могут быть беспорядочными.

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


13
Дженкинс теперь может получить более приятный графический интерфейс благодаря Blue Ocean
Аюб Каанич,

3
Начиная с gitlab 9.3 добавлена ​​поддержка многопроектного конвейера. Это было для меня одной из главных причин, почему я остановился на Дженкинсе. В настоящее время я занимаюсь PoC, чтобы проверить, могу ли я справиться с gitlab, так как они явно также сосредоточены на этом сейчас и развиваются намного быстрее. Кроме того, мне очень нравится пользовательский интерфейс и его развитие с течением времени.
Rik

4
Лучшее с файлами yaml - это то, что вы документируете свои изменения в конвейере прямо там, где он должен быть ... в репозитории как часть исходного кода. Таким образом, у вас могут быть ветки с разными файлами yaml для разных веток выпуска. Конечно, слияние yaml может быть беспорядком :) Слияние двух piplelines в jenkins - это намного сложнее.
Кристиан Мюллер

jenkins предоставляет гораздо больше инструментов, чем gitlab ci. Интеграция gitlab / jenkins Together возможна и действительно прозрачна для пользователя, если она хорошо настроена. слияние двух piplelines в jenkins легко с Jenkinsfile в вашем репозитории .... вам понадобятся плагины исходной ветки gitlab и gitlab
sancelot

1
Что имеется в виду под «Поддержка только одного файла в версии сообщества. Несколько файлов в версии для предприятий». ? Извините, я попытался прочитать прилагаемый выпуск, но не смог понять.
Лестер

62

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

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

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

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

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

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


5
Я полностью согласен с вами насчет Gitlab. На момент написания gitlab не был таким полным, как сейчас. Мне очень нравится Gitlab как инструмент, и я очень ценю всю работу, которую ребята вкладывают в него.
Rik

1
@alfageme: В любом случае я проверю ваши отчеты на указанном сайте: Спасибо за все ваши объяснения. В данный момент я собираюсь решить, будем ли мы использовать gitlabCI или Jenkins для нашего CI-материала.
Макс Шиндлер,

3
@Rik Мне нравится Gitlab CI, однако я слышу аргументы с другой стороны, говорящие о том, что трудно поддерживать файлы yaml, потому что нет возможности повторного использования, потому что многие файлы yaml в конвейере следуют той же структуре, а создание шаблонов не рассматривается как лучший вариант для jenkinsfile, потому что jenkinsfile использует файл groovy. так что все дело в коде и настройке для повторного использования. не могли бы вы поделиться своими мыслями по этому поводу?
user1870400

1
@ user1870400 Я не совсем понимаю, что вы имеете в виду под шаблонами. Потому что, насколько я понимаю, это просто файл в вашем репозитории. И это ничем не отличается от вашего Jenkinsfile. Вы правы, что у Jenkinsfileвас есть groovy (+ дополнительные java libs), доступные для запуска кода, где .gitlab-ci.yamlфайл будет в основном поддерживать оболочку, но (в зависимости от местоположения бегуна). С другой стороны, вы также можете вызвать все это из сценария оболочки, но обратная сторона заключается в том, что вы создаете зависимости между компьютерами (которые, на мой взгляд, не очень прозрачны).
Рик

1
@Alfageme - Я тоже начал использовать Gitlab CI и отошел от Jenkins. Я использую его в момент автоматической сборки, загрузки в Nexus, развертывания в DEV env и запуска модульных тестов. Такая последовательность выполняется на уровне проекта (стандарт). После DEV мне также нужно управлять развертыванием нескольких проектов (группа Gitlab). Я создал графический интерфейс, который использует Gitlab, Nexus API и т. Д., Где вы выбираете последний тег проекта для развертывания, а также развертываются последние теги групповых проектов (наивно). Я работаю над расширением для поддержки определения матрицы версий (projec1v1.1 совместим с project2v3.2), для этого я сделаю один запрос функции в gitlab.
kensai

22

Во-первых, на сегодняшний день 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 быстро восполнит пробел.


@ Питер Мортенсен: THX!
avi.elkharrat 06

6

Я хотел бы добавить некоторые выводы из моих недавних экспериментов с 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

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


0

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.