GitHub Actions, GitLab CI или Jenkins: сравнение CI/CD-инструментов

Короткий ответ

Все три инструмента умеют главное: собирать проект, запускать тесты и выкатывать код при каждом изменении. Разница — в том, где живёт ваш код и сколько времени вы готовы тратить на обслуживание самой CI-системы.

• GitHub Actions — встроен в GitHub, ничего не нужно разворачивать. Лучший выбор, если репозитории уже там.
• GitLab CI — встроен в GitLab (облачный или self-hosted). Удобен, когда нужен единый инструмент: код, задачи, реестр образов и CI в одном месте.
• Jenkins — отдельный open-source сервер. Максимально гибкий, работает с любым Git-хостингом, но требует постоянного ухода.

Сравнение по ключевым параметрам

Модель хостинга

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

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

GitLab в self-hosted варианте — промежуточный путь: весь стек на вашем сервере, но CI уже интегрирован и не требует отдельной сборки из плагинов.

Синтаксис конфигурации

GitHub Actions и GitLab CI используют YAML, который хранится в репозитории рядом с кодом. Пример простого пайплайна в GitHub Actions:

name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Аналог в GitLab CI:

test:
  image: node:20
  script:
    - npm ci
    - npm test

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

Раннеры и стоимость

Конкретные тарифы меняются, поэтому смотрите на факторы стоимости, а не на цифры из статей:

• Облачные минуты. GitHub и GitLab дают бесплатный лимит, дальше оплата за время работы раннеров. Цена зависит от ОС и мощности машины.
• Свои раннеры. Платите только за собственные серверы — выгодно при большом объёме сборок.
• Jenkins бесплатен как ПО, но вы оплачиваете серверы и, главное, время инженера на поддержку.
• Тариф платформы. Часть функций (расширенные правила доступа, аудит, окружения с одобрением) доступна только на платных планах.

Экосистема и расширения

• GitHub Actions Marketplace — тысячи готовых шагов: деплой в облака, уведомления, сканеры. Важно закреплять версии и проверять авторов.
• GitLab делает ставку на встроенные возможности: реестр контейнеров, сканирование безопасности, окружения, review apps. Конфигурации переиспользуются через include и компоненты.
• Jenkins имеет самую большую базу плагинов, но плагины обновляются с разной скоростью, конфликтуют между собой и становятся источником уязвимостей.

Что выбрать небольшой и большой команде

Небольшая команда или стартап:

• Код на GitHub — GitHub Actions.
• Код на GitLab — GitLab CI.
• Jenkins почти никогда не нужен: время на поддержку важнее экономии.

Крупная компания:

• Требование держать всё внутри периметра — self-hosted GitLab или GitHub Enterprise с собственными раннерами.
• Много легаси-процессов, нестандартные сборки, уже есть экспертиза — Jenkins остаётся рабочим вариантом.
• Разнородные репозитории на разных хостингах — Jenkins или единая платформа после миграции.

Частые ошибки

• Выбирать CI отдельно от Git-хостинга. Интеграция с pull/merge request — главный плюс встроенных решений.
• Хранить секреты в YAML. Используйте встроенные хранилища secrets и variables.
• Не кешировать зависимости. Сборки становятся медленными и дорогими.
• Ставить Jenkins «на всякий случай» без человека, который будет его обновлять.