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