Обзор CI/CD-платформ

Updated Jul 2026

Четыре основные платформы

Большинство команд в 2025 году используют одну из четырёх CI/CD-платформ. У каждой свой формат конфигурации и модель размещения, но все они разделяют одни и те же базовые концепции: триггеры, задачи (jobs), шаги (steps), переменные окружения, секреты и артефакты.

Общие концепции для всех платформ

Независимо от используемой платформы, следующие концепции работают одинаково. Понимание этих концепций делает переход между платформами простым.

Триггеры

Триггеры определяют, когда запускается пайплайн. Распространённые триггеры:

• Push в ветку: запуск при каждом push кода (наиболее частый для CI)
• Pull request / merge request: запуск при открытии или обновлении PR
• Расписание (cron): запуск по таймеру для ночных регрессионных тестов или проверки актуальности данных
• Ручной запуск: позволяет людям запускать пайплайны с параметрами (полезно для развёртывания в конкретные среды)
• Создание тега: запуск при push нового релизного тега

Задачи и шаги

Задача (job) — это единица работы, выполняемая на одной машине (раннере). Задачи могут выполняться параллельно или последовательно в зависимости от зависимостей. Шаг (step) — это отдельная команда или действие внутри задачи.

Pipeline
  └── Job A (выполняется первым)
       ├── Step 1: Получение кода
       ├── Step 2: Установка зависимостей
       └── Step 3: Запуск unit-тестов
  └── Job B (зависит от Job A)
       ├── Step 1: Получение кода
       ├── Step 2: Запуск интеграционных тестов
       └── Step 3: Загрузка отчётов о тестировании

Переменные окружения и секреты

Переменные окружения настраивают поведение без жёсткого кодирования значений. Секреты — это зашифрованные переменные окружения для конфиденциальных данных: API-ключей, паролей и токенов.

Правила работы с секретами:

• Никогда не коммитьте секреты в систему контроля версий
• Используйте хранилище секретов платформы (GitHub Secrets, GitLab CI Variables, Jenkins Credentials)
• Регулярно ротируйте секреты
• Ограничивайте область действия секретов минимально необходимым доступом (на уровне репозитория, а не организации, когда это возможно)

Раннеры

Раннер — это машина, на которой выполняется ваш пайплайн. Облачные раннеры предоставляются платформой (удобно, но с ограниченной настройкой). Собственные раннеры — это машины, которые вы обслуживаете сами (больше контроля, лучше для специализированного оборудования или доступа к внутренней сети).

Когда использовать собственные раннеры:

• Тестам нужен доступ к внутренним сервисам за файрволом
• Требуется специализированное оборудование (GPU, мобильные устройства)
• Объём пайплайнов делает облачные раннеры дорогими
• Требования комплаенса запрещают выход кода за пределы вашей сети

Выбор платформы

Для большинства команд выбор прост: используйте то, что интегрируется с вашей системой контроля версий. Если ваш код на GitHub — используйте GitHub Actions. Если на GitLab — используйте GitLab CI. Издержки от использования отдельной CI-платформы (например, Jenkins с GitHub) редко оправдывают преимущества.

Выбирайте Jenkins, когда:

• Вам нужны сложные, глубоко настроенные пайплайны с плагинами для нишевых инструментов
• У вас есть выделенная DevOps-команда для обслуживания инфраструктуры Jenkins
• В вашей организации уже есть зрелая настройка Jenkins

Выбирайте CircleCI, когда:

• Вам нужна максимальная скорость выполнения
• Ваша команда использует несколько платформ контроля версий
• Вы хотите использовать orbs (переиспользуемые пакеты пайплайнов) для сокращения шаблонного кода

Советы по платформам для QA

GitHub Actions

• Используйте actions/upload-artifact и actions/download-artifact для передачи результатов тестов между задачами
• Ключевое слово services запускает Docker-контейнеры (базы данных, очереди сообщений) как sidecar-сервисы для интеграционных тестов
• Используйте workflow_dispatch с входными параметрами, чтобы QA могли вручную запускать тесты для конкретных веток или окружений

GitLab CI

• rules и only/except управляют запуском задач — используйте их для пропуска дорогих тестов, когда изменилась только документация
• artifacts:reports:junit парсит JUnit XML и отображает результаты тестов прямо в merge request
• Review apps позволяют развернуть каждый merge request во временное окружение для ручного тестирования

Jenkins

• Используйте Jenkinsfile (декларативный или скриптовый pipeline) вместо freestyle-задач для воспроизводимости
• Плагин Blue Ocean предоставляет современный интерфейс для визуализации пайплайнов
• Shared libraries позволяют переиспользовать логику пайплайнов между несколькими проектами

CircleCI

• Orbs — это готовые шаги пайплайна. cypress/orb и playwright/orb могут сэкономить часы настройки
• Workspaces сохраняют данные между задачами в workflow (аналогично артефактам GitHub Actions, но легче)
• Разделение тестов с помощью circleci tests split автоматически распределяет тесты между параллельными контейнерами

Практическое упражнение

1. Выберите платформу, которую использует ваша команда (или GitHub Actions, если вы учитесь самостоятельно)
2. Создайте пайплайн, который:
   • Запускается при push и pull request
   • Содержит две задачи: lint и test
   • Задача test зависит от успешного прохождения lint
   • Использует кэширование зависимостей
   • Загружает результаты тестов как артефакты
3. Намеренно сломайте тест и убедитесь, что пайплайн завершается с ошибкой и создаёт полезные артефакты
4. Добавьте триггер по расписанию для ночного запуска

Это упражнение охватывает основы, применимые к любой платформе. После того как вы создадите один пайплайн с нуля, концепции будут переноситься на любую другую платформу.