Среди всех существующих CI/CD-инструментов есть два наиболее популярных — Jenkins и GitLab CI/CD. Хотя они решают схожие задачи, между ними есть отличия, которые важно учитывать. Мы пообщались с Кириллом Борисовым, старшим инженером-программистом VK, чтобы больше узнать о ключевых особенностях инструментов, разобраться в их сильных и слабых сторонах. 

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

Jenkins

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

Особенности 

Экосистема плагинов. Экосистема плагинов Jenkins выглядит более развитой по сравнению с экосистемами подключаемых модулей других CI/CD-инструментов. В настоящее время существует более 1500 плагинов, направленных на решение широкого спектра задач. 

Плагины упрощают работу, но при бездумном использовании могут вызывать проблемы. Во-первых они потребляют довольно много памяти. Во-вторых, некоторые из них некорректны — это обратная сторона опенсорсного комьюнити, когда написано вроде всё, но не всегда хорошо.

Исходя из своей практики, могу сказать, что около 80% задач можно решить с помощью плагинов. Оставшиеся 20% — посредством «допилов».

Порог входа. Я считаю, что порог входа у Jenkins чуть выше, чем у GitLab CI/CD, потому что GitLab CI/CD — это YAML, который многие знают и любят. Однако однажды разобравшись в Jenkins, вы почувствуете всю силу инструмента и вряд ли захотите использовать что-то ещё. 

Популярность. Очень много проблем, возникающих в работе с Jenkins, достаточно легко гуглятся, потому что они уже возникали у других людей. Это значительно повышает шансы найти решение. Кроме того, существует немало чатов, куда вы всегда можете обратиться за помощью и оперативно получить её. 

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

Слабые стороны

К слабым сторонам Jenkins обычно относят архитектуру. Проблема в том, что весь код выполняется на мастере, что может приводить к падениям и некоторым другим негативным последствиям. 

Что это значит? Вам придётся приложить больше усилий, чтобы превратить Jenkins в надежный инструмент. Просто поставить его и ожидать, что всё будет работать, не получится.  

В комьюнити Jenkins около 4 лет ведутся разговоры о том, что стоит изменить архитектурное устройство инструмента. Однако пока всё остаётся только на уровне разговоров. 

Gitlab CI/CD

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

Особенности

Расширения. В дефолтной версии Jenkins имеет ограниченный функционал. «Мясом» и дополнительными возможностями он обрастает за счет расширений. Gitlab CI/CD — готовая система, в которой есть всё для выкатки кода в прод. 

С одной стороны, это удобно, но с другой, накладывает ограничения — вы вынуждены подстраиваться под требования Gitlab CI/CD. Jenkins в этом смысле более гибкий — можно настраивать его так, как удобно. 

Востребованность. У меня нет точной статистики по использованию Gitlab CI/CD, но его популярность бесспорно растёт. Отчасти это связано с тем, что многие полезные фишки, которые были платными, начали перетаскивать в бесплатную комьюнити-версию. Отчасти — с распространенностью YAML

По опыту собеседований в крупные компании могу сказать, что Jenkins не сдаёт позиций — его тоже активно используют. Некоторые организации вообще не ограничиваются чем-то одним. В одной компании команды могут использовать разные инструменты. Какие-то команды используют Gitlab CI/CD, какие-то — Jenkins. Выбор определяется опытом, имеющимися навыками и задачами, которые предстоит решать. 

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

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

Ограничение доступа к репозиториям. В Jenkins вам приходится отдельно разграничивать доступ. В GitLab CI/CD  тем, кто совместно работает над проектом, вы можете назначать права, соответствующие их ролям. Это особенно актуально для корпоративных проектов. 

Слабые стороны

В Jenkins вы можете взять язык программирования Groovy или Java и написать код, тесты и др. В GitLab CI/CD придётся обходиться bash-скриптами. Это, конечно, дело вкуса, но мне такой подход не нравится, так как огромное количество баш-кода тяжело считать.

От чего зависит выбор CI/CD-инструмента

Когда лучше использовать Jenkins, а когда — GitLab CI/CD? Многое зависит от знаний, навыков и опыта человека, который будет поддерживать СI/CD-процесс. На практике это часто оказывается одним из важнейший ориентиров при выборе инструмента. 

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

Для нетривиальных задач больше подойдёт Jenkins. В качестве языка для Jenkins Pipeline скрипта был выбран Groovy. Это позволяет вам описывать сложные процессы на языке программирования. Для сравнения в GitLab CI/CD используется либо кастомный Python, либо Bash, который смотрится довольно странно в кейсах, где нужно взаимодействовать сразу с несколькими системами и получать от них ответы.

Личный опыт: почему выбрал Jenkins

Когда я только начинал работать, такого огромного выбора не было. Фактически существовало три варианта: тогда ещё платный TeamCity, только зарождающийся Gitlab CI/CD и Jenkins. Последний считался эталонным инструментом, который использовался во многих компаниях и часто упоминался в тематических статьях. На старте этого было достаточно, чтобы сделать выбор в его пользу. 

По ходу работы я всё больше проникался Jenkins. И, признаюсь честно, до сих пор не понимаю, как те задачи, что мы решали с его помощью, можно было бы выполнить посредством Gitlab CI/CD. Один из примеров — интеграция Wiki, когда мы собирали версии всех зарелизенных компонентов, постили их в git, готовили Jira-отчёты и тому подобное. 

Свой выбор я сделал давно, и, конечно, с тех пор многое изменилось. Gitlab CI/CD сильно преуспел и получил много разных фич. Однако это не отменяет того факта, что Jenkins остаётся отличным инструментом CI/CD и автоматизации в целом. 

Недавно проводил импровизированный опрос, чтобы понять, какой из инструментов востребованнее. Выяснилось, что GitLab CI любят чуть больше, чем Jenkins. При этом Jenkins ценят за универсальность и способность решать сложные задачи. Отсюда простой вывод: когда нужно что-то простое и быстрое — выигрывает GitLab CI. Если же на кону нетривиальный процесс для энтерпрайз — Jenkins.