Если вы хотите ускорить доставку программного обеспечения за счет автоматизации, важно внедрить конвейер CI / CD. А в сфере непрерывной интеграции и доставки доминируют два инструмента с открытым исходным кодом – GitLab CI и Jenkins.
Как руководителям инженерных команд сделать выбор между многофункциональным GitLab, предлагающим комплексный подход, и проверенной в бою гибкостью Jenkins? Давайте подробно сравним эти платформы, чтобы вы могли принять правильное решение о CI/CD для своей организации.
Почему важна непрерывная интеграция и доставка (CI/CD)
Во-первых, что мы подразумеваем под непрерывной интеграцией и доставкой?
Непрерывная интеграция (CI) — это практика частого объединения изменений кода разработчиков в общий репозиторий кода несколько раз в день. Каждая интеграция запускает автоматизированный процесс сборки и тестирования для выявления проблем на ранних этапах.
Непрерывная поставка и развёртывание (CD) выводят интеграцию на новый уровень, обеспечивая надёжную доставку изменений кода пользователям. CD предполагает последовательное автоматизированное тестирование и развёртывание в производственных средах.
Внедрение практик CI/CD позволяет инженерным командам сокращать циклы итераций и быстрее внедрять инновации. Удовлетворенность разработчиков также повышается — исследование DORA 2021 показало, что высококвалифицированные специалисты, использующие CI/CD, могут решать критические производственные проблемы менее чем за час.
Но чтобы воспользоваться этими преимуществами, организациям нужна надёжная основа CI/CD. Именно здесь на помощь приходят GitLab и Jenkins.
Краткая история GitLab CI и Jenkins
Прежде чем сравнивать функции, давайте посмотрим, где появился каждый из этих инструментов.
Jenkins ведет свою историю от Hudson — сервера непрерывной интеграции на базе Java с открытым исходным кодом, созданного в 2004 году. После внутреннего конфликта сообщество Hudson в 2011 году отделило проект от Hudson и создало Jenkins. Спустя более 15 лет поддержки критически важных конвейеров в различных отраслях Jenkins остается отраслевым стандартом.
GitLab CI появился гораздо позже, в 2014 году, как собственный компонент непрерывной интеграции, встроенный непосредственно в GitLab наряду с возможностями размещения кода. Сам GitLab был запущен двумя годами ранее, в 2012 году, как альтернатива GitHub и другим репозиториям кода с открытым исходным кодом.
Благодаря интегрированному подходу популярность GitLab CI неуклонно растёт, особенно среди компаний, ориентированных на цифровые технологии.
Статистика внедрения и использования
С точки зрения реального использования, Jenkins пользуется невероятной популярностью и по состоянию на 2022 год насчитывает более 300 000 активных установок. По данным SlashData, в мире около 30% программистов используют Jenkins для нужд CI/CD.
Хотя его сложнее точно отследить как встроенный модуль GitLab, по оценкам G2, более 13 000 компаний активно используют GitLab CI на основе более чем 18 000 отзывов на Glassdoor, в которых упоминается компонент CI/CD.
Независимо от того, какая платформа лидирует по общему количеству пользователей, и Jenkins, и GitLab CI, несомненно, составляют значительную часть рынка CI/CD, ежедневно поддерживая миллионы разработчиков.
Архитектурные различия
Одно из самых больших различий между обеими платформами заключается в базовой архитектуре и требованиях к инфраструктуре.
В Jenkins используется архитектура master / slave. Централизованный контроллер Jenkins обрабатывает планирование заданий сборки. Затем он делегирует фактическое выполнение динамически подготавливаемым узлам-агентам. Агенты автоматически регистрируются у мастера для обработки сложных рабочих нагрузок, таких как компиляция кода, выполнение тестов и управление развертываниями.
Такое разделение задач обеспечивает Jenkins огромную гибкость. Команды могут масштабировать рабочие нагрузки, запуская больше агентов в существующей инфраструктуре или автоматически масштабируясь в облаках. Настройка конкретных агентов для выполнения определённых задач также помогает эффективно управлять конвейерами. Архитектура Jenkins гарантирует, что даже при больших масштабах контроллер остаётся лёгким и отзывчивым.
GitLab CI использует более простую архитектуру, состоящую в основном из веб-приложения GitLab и бегунков GitLab CI. Эти специальные процессы выполняют задания, определённые в .gitlab-ci.yml файлах, хранящихся вместе с исходным кодом репозитория.
В отличие от агентов Jenkins, бегунки не регистрируются автоматически на центральном сервере. Команды должны вручную настраивать каждый агент-бегунок и регистрировать его для работы с проектами по мере необходимости. Вместо того чтобы разделять обязанности по координации и выполнению сборки, GitLab объединяет всё в одном приложении.
Такая простота упрощает настройку и управление для небольших команд. Но поддержание производительности в больших масштабах ложится дополнительным бременем непосредственно на экземпляры приложения GitLab и более мощные серверы. Масштабирование GitLab CI требует одновременного обновления спецификаций сервера GitLab и серверов.
Подходы к настройке конвейера
Еще одно ключевое отличие заключается в том, как конвейеры определяются и настраиваются с помощью кода.
Jenkins с самого начала использовал подход «конфигурация как код» с помощью Jenkinsfile. Этот простой текстовый файл использует специализированный язык на основе Groovy (или, при необходимости, YAML) для описания всех этапов, триггеров, логики выполнения и параметров среды в конвейере.
Файлы Jenkins существуют отдельно от кодовых баз приложений, что позволяет командам определять конвейеры так, как они считают нужным. Jenkins также поддерживает настройку последовательных заданий с входными, выходными данными и зависимостями через пользовательский интерфейс на основе браузера.
GitLab CI использует файл .gitlab-ci.yml в корневом каталоге соответствующего репозитория кода. Вместо проприетарных DSL в этом определении конвейера используется знакомый синтаксис YAML.
Сохранение конфигураций вместе с кодом в системе контроля версий обеспечивает синхронизацию и единый источник достоверных данных. Но из-за ограниченных возможностей YAML сложные конвейеры в GitLab могут быть сложнее в использовании.
На практике YAML позволяет быстрее приступить к работе, в то время как Jenkinsfiles/скрипты обеспечивают расширенную гибкость.
Простота использования
Поскольку сложность программного обеспечения постоянно растёт, простота использования остаётся ключевым фактором при оценке корпоративных платформ, таких как инструменты CI/CD.
GitLab CI предлагает более плавный процесс начальной адаптации по сравнению с Jenkins. Синтаксис YAML снижает начальную кривую обучения кодированию конвейеров по сравнению с Groovy scripting. Полностью веб-интерфейс также упрощает настройку по сравнению с фрагментированным браузером и терминалом Jenkins.
Интеграция непосредственно в полноценный продукт GitLab также означает, что разработчикам не нужно переключаться между системами. Единая аутентификация, разрешения и интерфейсы делают GitLab единым решением для DevOps, а не набором отдельных инструментов.
Jenkins предоставляет беспрецедентные возможности настройки для тех, кто готов разобраться в тонкостях. Но даже опытным разработчикам может быть сложно сориентироваться на начальном этапе. Более крутая кривая обучения приводит к более длительному времени, необходимому для получения результата, и большей зависимости от труднодоступных знаний.
Однако широкий выбор доступных плагинов позволяет командам упростить работу с Jenkins, настроив его под свои нужды.
Экосистема плагинов и интеграции
Ключевым преимуществом, способствующим быстрому распространению Jenkins на протяжении многих лет, является его обширная интеграция с сообществом. Разработчики по всему миру создали более 1800 плагинов, которые легко подключаются к Jenkins благодаря его модульной архитектуре.
Эта обширная библиотека расширений позволяет интегрировать Jenkins практически со всеми основными инструментами DevOps, такими как Docker, Kubernetes, Terraform, AWS и другими. Команды используют плагины Jenkins для обеспечения безопасности, уведомлений, интеграции с программным обеспечением и даже пользовательских интерфейсов. Плагины позволяют настраивать конвейеры в соответствии с уникальными потребностями каждой организации.
GitLab CI предлагает меньший набор встроенных интеграций, сосредоточенных в основном вокруг экосистемы GitLab. Компонент Auto DevOps действительно предоставляет шаблоны приложений, рекомендации по лучшим практикам и автоматизацию развертывания рабочих нагрузок в Kubernetes простым вводом кода.
Поначалу такой подход с замкнутым циклом удобен, но в конечном итоге он ограничивает возможности по мере взросления команд. GitLab CI обеспечивает оптимизацию при соблюдении очень стандартизированных рабочих процессов, но в остальных случаях предоставляет меньше гибкости.
Масштабируемость
Для крупных инженерных организаций и предприятий, внедряющих инновации, надежное масштабирование возможностей CI/CD остается обязательным условием. Обе платформы предлагают проверенные модели для расширения, но существенно отличаются друг от друга.
Jenkins отлично справляется с огромными нагрузками на конвейеры. Разделение на мастер- и агентские узлы обеспечивает независимую координацию рабочей нагрузки и масштабирование выполнения. Протоколы автоматической регистрации позволяют мгновенно запускать тысячи временных агентов. Благодаря плагинам для интеграции с облаком команды могут запускать задания Jenkins практически на неограниченных ресурсах инфраструктуры.
Реальные примеры, такие как использование компанией Samsung более 15 000 узлов Jenkins, демонстрируют экстремальный горизонтальный масштаб в действии. Архитектура Jenkins означает, что независимо от того, сколько ежедневных сборок, тестов или развёртываний выполняется, конвейеры продолжают работать.
GitLab CI традиционно централизовал функции на одном сервере, что требовало вертикального масштабирования. Дополнительные расходы на резервные серверы помогают, но также увеличивают нагрузку. Последние версии позволяют объединять экземпляры GitLab с помощью глобальной балансировки нагрузки CI. Несмотря на повышение горизонтальной производительности, для координации по-прежнему требуются более мощные серверы.
Успешное масштабирование конвейеров в конечном счёте сводится к оптимизации рабочих процессов и соблюдению рекомендуемых операционных порогов.
Несмотря на то, что Jenkins способен обрабатывать большие объёмы данных, он, как правило, более эффективно работает в больших масштабах по сравнению с альтернативами GitLab. Это позволяет Jenkins выполнять самые сложные корпоративные задачи CI/CD по всему миру.
Безопасность
Поскольку автоматизация CI/CD затрагивает критически важные для бизнеса системы и код, безопасность занимает важное место при сравнении вариантов. Мы вкратце опишем основные моменты.
Поскольку Jenkins служит центральным узлом, управляющим выполнением конвейеров, крайне важно усилить защиту главного сервера и тщательно ограничить доступ. Необходимо проверять плагины на безопасность, учитывая риски, связанные со сторонними расширениями. Агенты, обрабатывающие конфиденциальные процессы, также требуют контроля и изоляции.
Безопасность GitLab CI в основном сосредоточена на основном приложении GitLab и бегунках. Необходимо ужесточить контроль доступа, сохранив при этом возможность самостоятельного обслуживания разработчиками. Принятие вкладов требует тщательной проверки, чтобы избежать атак на цепочку поставок, влияющих на стек CI/CD.
Оба решения также предоставляют функции, ориентированные на безопасность, но должны интегрироваться с существующими решениями для шифрования, управления секретными данными, аутентификации по единому входу и так далее. Мы не будем углубляться в детали, но рекомендуем использовать принцип наименьших привилегий и другие передовые методы работы с инструментами CI/CD.
Коммерческие и управляемые варианты
И Jenkins, и GitLab изначально создавались как проекты с открытым исходным кодом, но также предлагают коммерческие версии и варианты управляемого хостинга.
Jenkins по-прежнему находится под управлением основателя Hudson Косукэ Кавагути и поддерживается CloudBees. Помимо Jenkins с открытым исходным кодом, CloudBees предоставляет несколько управляемых дистрибутивов Jenkins, корпоративные плагины, услуги по устранению неполадок, обучение и многое другое.
Управляемые планы хостинга CloudBees CI обеспечивают оптимизированные среды Jenkins на AWS или в Google Cloud для команд из 15 и более человек. Пользовательские развертывания позволяют запускать CloudBees CI в частной инфраструктуре, а также для обеспечения безопасности с разделением.
GitLab предлагает свои возможности CI/CD с открытым исходным кодом в качестве компонента более широкого набора продуктов GitLab. Компания GitLab Inc. продает подписки в основном крупным организациям, которые получают доступ к таким функциям, как сканирование безопасности, контроль соответствия требованиям и повышение скорости работы модуля CI/CD.
Для команд, которые хотят передать управление на аутсорсинг, GitLab.com предоставляет GitLab Enterprise Edition, предустановленную в общедоступной облачной инфраструктуре. Как в случае с самостоятельным управлением, так и в случае с SaaS-решениями предоставляются профессиональные услуги по правильной настройке платформ в соответствии с потребностями каждой организации.
Какие организации используют GitLab CI против Jenkins?
Помимо сравнения функций, полезно взглянуть на реальные примеры реализации.
Являясь отраслевым стандартом на протяжении многих лет, Jenkins лежит в основе критически важных конвейеров CI/CD практически на каждом крупном предприятии. Гибкая архитектура легко интегрируется с собственными стеками, что снижает риски при миграции. Wells Fargo, eBay, Uber, Netflix, Reddit, Spotify — все они являются приверженцами Jenkins, использующими его в своих экосистемах разработки.
Опрос CloudBees 2022 года, в котором приняли участие 800 ИТ-специалистов, принимающих решения, показал, что 61% из них активно используют Jenkins, а ещё 25% планируют начать использовать его в течение года. 85% согласны с тем, что Jenkins повышает качество программного обеспечения, что подтверждает его репутацию.
GitLab CI, как правило, чаще внедряется среди «рожденных в облаке» цифровых аборигенов с потребностями в новой инфраструктуре. Объединяя возможности CI / CD с современными инструментами управления репозиториями кода, отслеживания проблем, планирования и безопасности, GitLab предоставляет растущим стартапам интегрированный стек DevSecOps.
Такие быстрорастущие компании, как Goldman Sachs, NASDAQ, Sony, IBM, Oracle, CERN, SpaceX, Screwfix и другие, используют GitLab CI для своих гибких конвейеров разработки в соответствии с официальной страницей для клиентов. Это решение CI/CD легко интегрируется с собственными инструментами ChatOps, сканированием безопасности и источниками данных для мониторинга.
В то время как большинство заголовков посвящены новоиспечённым «единорогам», выбирающим GitLab, даже традиционные предприятия часто используют его для инициатив по цифровой трансформации в сфере мобильных приложений, Интернета вещей и машинного обучения, созданных с использованием облачных технологий.
Рекомендации экспертов по сравнению инструментов CI / CD
Помимо технических возможностей, отраслевые перспективы дают полезную информацию. Давайте рассмотрим мнения нескольких лидеров мнений в области DevOps.
«Jenkins и GitLab изначально нацелены на удовлетворение немного разных потребностей, но предприятиям следует рассматривать оба инструмента как часть комплексной стратегии CI/CD». — Каспар Компес, руководитель отдела автоматизации CI/CD в Anduril
«YAML, безусловно, позволяет быстрее приступить к работе, но Groovy [в Jenkins] гораздо более функционален для продвинутых сценариев. К счастью, изучение основ применимо к обоим вариантам». — Кармен ДеАрдо, консультант по DevOps/блогер
«Не думайте, что GitLab CI по своей сути проще из-за использования YAML вместо скриптов. Абстракция приводит к утечкам при масштабировании. Гибкость Jenkins, несмотря ни на что, лучше подходит для ежедневных конвейеров с 6-9 цифрами, критически важных для многих отраслей». — Дэвис У. Норрис, старший архитектор DevOps в CloudSphere
Эти опытные специалисты справедливо отмечают, что потребности каждой команды разработчиков программного обеспечения отличаются. Прежде чем выбирать между GitLab и Jenkins, сначала тщательно оцените требования вашей организации, набор навыков, приложения и инфраструктуру.
На многих предприятиях обе платформы фактически дополняют друг друга, поскольку компании стандартизируют конвейеры CI/CD. Вместо того чтобы использовать один инструмент для решения всех задач, можно создать матрицу CI/CD, использующую несколько решений, которая в долгосрочной перспективе может оказаться более эффективной.
Облачные варианты: GitLab vs. Jenkins vs. Argo CD / Tekton
Для организаций, заинтересованных в оптимальном CI/CD для Kubernetes, сторонние облачные решения также заслуживают внимания наряду с традиционными платформами (или поверх них).
Такие инструменты, как Argo CD, специализируются на применении методов развёртывания и продвижения контейнеров GitOps в различных средах. Tekton создаёт специализированные конвейеры на основе Kubernetes, использующие декларативные принципы.
Оценка этих многообещающих стартапов выходит за рамки нашего текущего исследования, в котором мы сравниваем GitLab и Jenkins. Но понимание возможностей, которые предоставляют такие современные решения, и сравнение их с устаревшими подходами будут становиться всё более актуальными в ближайшие годы по мере ускорения облачных преобразований.
Какую платформу CI / CD выбрать?
Итак, учитывая всё вышесказанное, как технологическим руководителям выбрать между Jenkins и GitLab CI? Или использовать и то, и другое в рамках более широких стратегий?
Вот краткое руководство по принятию решения:
Когда выбрать GitLab CI:
- Вы хотите, чтобы CI / CD изначально был интегрирован в полноценную платформу DevOps
- Ваша команда считает, что с YAML работать проще, чем с конвейерными сценариями
- Вам не нужен высокий уровень настройки или сторонние интеграции
- Рабочие нагрузки вашего конвейера относительно невелики или средней сложности
Когда выбрать Jenkins:
- У вас особые требования к инфраструктуре, не поддерживаемые архитектурой GitLab
- Вашей организации требуются сложные конвейеры CI / CD и кастомизация
- Требуются критически важные или расширенные возможности CI / CD корпоративного масштаба
- Бюджет сильно ограничен, и вам требуется только чистая функциональность CI / CD
- Ваша команда предпочитает писать скрипты, а не YAML, для удобства конвейерной переносимости
Для крупных предприятий внедрение обеих платформ является обычным делом:
- Устаревшие Java-приложения полагаются на закаленные в боях конвейеры Jenkins
- Облачные приложения с нуля используют GitLab CI, интегрирующийся с Kubernetes
- Jenkins занимается координацией конвейеров огромного масштаба
- GitLab управляет современными, но менее сложными рабочими процессами CI / CD
Вместо того чтобы привязываться к одному решению, современные организации-разработчики используют матрицу CI/CD, применяя несколько специализированных инструментов там, где каждый из них наиболее эффективен.
Оцените свои критерии соответствующим образом — навыки, процессы, приложения, требования к доставке и реалии инфраструктуры. Это окончательное сравнение является лишь отправной точкой для команд, которые хотят определить оптимальное решение для CI/CD.
Теперь, имея полное представление о преимуществах Jenkins и GitLab, руководители технологических компаний могут создавать гибкие конвейеры, адаптированные к потребностям предприятий в 2023 году и в последующие годы!
Сравнение Jenkins и GitLab CI/CD
Jenkins и GitLab CI/CD — это отличные инструменты, каждый из которых в отдельности может реализовать работу пайплайн CI/CD-конвейера. Давайте попробуем сравнить их.
| Характеристика | Jenkins | GitLab CI/CD |
| Открытый или закрытый код | Открытый код | Открытый код |
| Установка | Требуется. | Не требуется, так как это — встроенная возможность платформы GitLab. |
| Уникальные особенности | Поддержка плагинов. | Глубокая интеграция в систему управления версиями. |
| Поддержка | Отсутствует. | Имеется. |
| Установка и настройка | Сложностей не вызывают | Сложностей не вызывают |
| Самостоятельное развёртывание системы | Это — единственный вариант использования системы. | Поддерживается. |
| Создание CI/CD-конвейеров | Поддерживается, используется Jenkins Pipeline. | Поддерживается. |
| Мониторинг производительности приложений | Отсутствует. | Имеется. |
| Экосистема | Существует более 1000 плагинов. | Система развивается в рамках GitLab. |
| API | Поддерживает развитую систему API. | Предлагает API для более глубокой интеграции в проекты. |
| Поддержка JavaScript | Имеется. | Имеется. |
| Интеграция с другими инструментами | Поддерживается интеграция с другими инструментами и платформами (Slack, GitHub). | Множество средств для интеграции со сторонними системами, в частности — с GitHub и Kubernetes. |
| Контроль качества кода | Поддерживается — с помощью плагина SonarQube и других плагинов. | Поддерживается. |
Различия между Jenkins и GitLab CI/CD
Описав и сравнив Jenkins и GitLab CI/CD, давайте сосредоточимся на различиях этих DevOps-инструментов. Знание об этих различиях позволит понять тех, кто предпочитает один из этих инструментов другому.
- GitLab CI/CD может полностью контролировать Git-репозитории. Речь идёт об управлении ветками репозиториев и о некоторых других возможностях. А вот Jenkins, хотя и умеет работать с репозиториями, не даёт такого же уровня контроля над ними, как GitLab CI/CD.
- Jenkins — это бесплатный опенсорсный проект. Тот, кто его выбирает, разворачивает его самостоятельно. А GitLab CI/CD включён в состав платформы GitLab, это готовое решение.
- GitLab CI/CD поддерживает развитые средства управления задачами, работающие на уровне проектов. Эта сторона Jenkins развита слабее.
Jenkins и GitLab CI/CD: сильные и слабые стороны
Сейчас у вас сложилось некоторое представление о Jenkins и GitLab CI/CD. Теперь, чтобы вы ещё лучше познакомились с этими инструментами, давайте разберём их сильные и слабые стороны. Полагаем, что вы уже приняли решение о том, какой именно инструмент вам нужен. Хочется надеяться, этот раздел позволит вам проверить себя.
Сильные стороны Jenkins
- Большое количество плагинов.
- Полный контроль над установкой инструмента.
- Простая отладка раннеров.
- Простая настройка узлов.
- Простое развёртывание кода.
- Очень хорошая система управления учётными данными.
- Гибкость и универсальность.
- Поддержка различных языков программирования.
- Система понятна на интуитивном уровне.
Слабые стороны Jenkins
- При использовании плагинов могут возникать сложности.
- При использовании Jenkins в маленьких проектах затраты времени, необходимые на его самостоятельную настройку, могут оказаться неоправданно большими.
- Отсутствие общих аналитических сведений по CI/CD-цепочкам.
Сильные стороны GitLab CI/CD
- Хорошая интеграция с Docker.
- Простое масштабирование раннеров.
- Параллельное выполнение задач, входящих в состав стадий CI/CD-конвейера.
- Использование модели ориентированного ациклического графа при настройке взаимоотношений задач.
- Высокий уровень масштабируемости за счёт возможности параллельного выполнения раннеров.
- Лёгкость добавления задач.
- Простое разрешение конфликтов.
- Надёжная система безопасности.
Слабые стороны GitLab CI/CD
- Для каждой задачи нужно описывать и загружать/выгружать артефакты.
- Нельзя протестировать результаты объединения веток до их фактического объединения.
- При описании стадий CI/CD-конвейера в них пока нельзя выделять отдельные этапы.
Итоги
И Jenkins, и GitLab CI/CD имеют сильные и слабые стороны. Ответ на вопрос о том, что именно выбрать, зависит от нужд и особенностей конкретного проекта. Каждый из рассмотренных сегодня CI/CD-инструментов отличается определёнными особенностями, хотя созданы эти инструменты для решения одной и той же задачи. При этом Jenkins — это автономный инструмент, а GitLab CI/CD — это часть платформы, предназначенной для совместной работы над кодом.
Выбирая CI/CD-систему стоит, помимо её возможностей, принимать во внимание и те затраты, которые могут быть с ней связаны, и то, с чем именно привыкли работать DevOps-инженеры, поддерживающие проект.
Какими CI/CD-инструментами вы пользуетесь?