- GitLab CI
- GitHub Actions
- Jenkins
Логика одна, различается остальное
Сначала про общее. Любой из этих инструментов делает одно и то же: запускает пайплайн из этапов, который вы видели в Анотомии, проверить, собрать, выкатить. Все они слушают события в репозитории, гоняют этапы по очереди, останавливаются на упавшем и показывают результат. Эта суть везде совпадает.
Расходятся инструменты по трем вещам: где инструмент живет, как описывается пайплайн и кто выполняет команды. По этим трем осям они и различаются.
GitLab CI, встроен в платформу
GitLab CI, это часть самого GitLab. Отдельно ничего ставить не нужно: репозиторий, пайплайны и реестр образов живут в одном месте. Пайплайн описывается YAML-файлом .gitlab-ci.yml прямо в репозитории. А раз конфиг лежит рядом с кодом, он версионируется вместе с ним: видно, кто и когда менял процесс доставки. Команды джоб выполняет программа-исполнитель, в GitLab она называется раннером.
Jenkins, отдельный сервер-ветеран
Jenkins устроен иначе. Это не часть платформы с кодом, а отдельный сервер, который вы сами поднимаете, настраиваете и обслуживаете. Репозиторий сообщает ему о новом коммите, Jenkins забирает код и раздает работу своим исполнителям, у него они зовутся агентами. Появился он намного раньше остальных, про его имя-дворецкого мы уже вспоминали на первом шаге, и за эти годы оброс огромной экосистемой.
Главной силой Jenkins является гибкость. Под него написаны тысячи плагинов почти на любой случай, и собрать можно пайплайн какой угодно сложности. Та же гибкость оборачивается и слабостью: сервер надо держать живым и обновлять, плагины конфликтуют и ломаются, а конфигурация исторически собиралась кликами в веб-интерфейсе. Позже появился свой файл-описание, Jenkinsfile, но на отдельном языке, не таком простом, как YAML. Поэтому Jenkins чаще встречается там, где он стоит давно или где нужна нестандартная логика, которую встроенные инструменты не вытягивают, в энтерпрайзе, банках, на больших легаси-системах.
Факт. У Jenkins больше полутора тысяч плагинов, и это одновременно его суперсила и его проклятие. Любую интеграцию можно добавить готовым плагином, но каждый плагин нужно обновлять, они зависят друг от друга и иногда ломают сборку после обновления. Встроенные инструменты пошли по обратному пути: меньше всемогущества, зато почти нечему ломаться.
И еще GitHub Actions
Третий заметный игрок, GitHub Actions, встроенный в GitHub по тому же принципу, что GitLab CI в GitLab. Конфиг тоже YAML, только файлы лежат в папке .github/workflows. У него есть маркетплейс готовых блоков-actions, которые подключаются одной строкой. По духу это близнец GitLab CI: выбор между ними обычно сводится к тому, на какой платформе уже лежит код.
Факт. GitHub Actions появился лишь в 2019 году, на полтора десятилетия позже корней Jenkins. То, что новичок так быстро стал одним из главных инструментов, хорошо показывает общий сдвиг: индустрия уходит от отдельных CI-серверов к встроенным в платформу YAML-пайплайнам рядом с кодом.
Как выбрать
| GitLab CI / GitHub Actions | Jenkins | |
|---|---|---|
| Где живет | встроен в платформу с кодом | отдельный сервер, поднимаете сами |
| Конфиг | YAML-файл в репозитории | Jenkinsfile (Groovy) или клики в UI |
| Исполнители | раннеры, часто в контейнерах | агенты (nodes) |
| Настройка | почти ноль, все готово | поставить, настроить, обслуживать |
| Сила | простота, конфиг рядом с кодом | гибкость, тысячи плагинов |
| Где встретишь | большинство современных команд | энтерпрайз, банки, легаси |
Правило тут простое. Начинать и в большинстве проектов работать стоит со встроенным инструментом, GitLab CI или GitHub Actions: ничего не нужно поднимать, конфиг лежит с кодом, порог входа минимальный. Jenkins выбирают осознанно, когда он уже стоит в компании или когда нужна экстремальная гибкость и плагины, которых у встроенных нет. Поэтому дальше мы идем на GitLab CI: он встроен, бесплатен для старта и закрывает почти все типовые задачи.
Причем здесь DevOps
Выбор инструмента CI/CD и поддержка пайплайнов в нем, повседневная работа девопса, и часто инструмент достается уже выбранным: пришли в команду, а там Jenkins, который крутится годами, или, наоборот, GitLab CI рядом с кодом. Поэтому полезно понимать не один инструмент, а саму развилку: встроенный в платформу против отдельного сервера, YAML рядом с кодом против плагинов и гибкости. Суть, этапы, джобы, исполнители, у всех одна, и, разобравшись с одним, на другой вы перейдете быстро.