Что такое CI/CD: интеграция, доставка и развёртывание

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

CI/CD — это практики и автоматизированный конвейер, который проверяет изменение кода и готовит его к выпуску. CI, continuous integration, регулярно собирает проект и запускает проверки. CD может означать continuous delivery — готовность проверенной версии к ручному выпуску — или continuous deployment, когда успешное изменение развёртывается автоматически.

CI/CD не равен одному YAML-файлу и не гарантирует качество сам по себе. Надёжный pipeline опирается на воспроизводимую сборку, полезные тесты, управляемые секреты, изолированные окружения, наблюдаемость и понятный откат.

CI, delivery и deployment: в чём разница

Слово CD неоднозначно, поэтому в документации проекта лучше писать delivery или deployment полностью. Ручное подтверждение production-релиза не делает процесс «неавтоматизированным»: оно может быть осознанным контрольным барьером.

Как работает CI/CD pipeline

1. Триггер. Push, pull request, merge request, тег, расписание или ручной запуск создаёт pipeline.

2. Чистое окружение. Runner получает код и заявленные зависимости.

3. Проверки. Запускаются форматирование, линтер, статический анализ и тесты, подходящие проекту.

4. Сборка артефакта. Создаётся один идентифицируемый пакет, бинарный файл или образ.

5. Проверка безопасности. Анализируются зависимости, секреты и собранный артефакт.

6. Staging. Та же версия развёртывается в тестовом окружении и проходит smoke- или end-to-end-проверки.

7. Production. Выпуск запускается автоматически либо после подтверждения.

8. Наблюдение и откат. Команда видит состояние релиза и может вернуть предыдущую рабочую версию.

В документации GitLab pipeline состоит из jobs и stages: задания внутри этапа могут выполняться параллельно, а последующие этапы обычно не стартуют после ошибки. В GitHub Actions workflow задаётся YAML-файлом, содержит события, jobs и steps и хранится вместе с кодом.

Минимальная конфигурация как модель

Синтаксис зависит от платформы, а команды — от проекта. Упрощённая схема ниже показывает порядок, а не готовый production-рецепт:

stages:
  - verify
  - build
  - deploy

tests:
  stage: verify
  script:
    - ./scripts/install-dependencies
    - ./scripts/run-tests

package:
  stage: build
  script:
    - ./scripts/build-artifact
  artifacts:
    paths:
      - output/

deploy-staging:
  stage: deploy
  script:
    - ./scripts/deploy staging

Реальные команды должны завершаться ненулевым кодом при ошибке. Закрепляйте версии среды и зависимостей, не печатайте секреты в лог, задавайте срок хранения артефактов и ограничивайте деплой правилами веток и окружений.

Зачем CI/CD проекту

• одинаковые проверки запускаются для каждого изменения;

• ошибка связывается с конкретным коммитом;

• сборка воспроизводится вне компьютера разработчика;

• ревьюер видит результаты тестов до слияния;

• релиз использует известный артефакт, а не случайное состояние сервера;

• действия и права деплоя можно журналировать;

• маленькие выпуски проще наблюдать и откатывать.

Польза зависит от качества обратной связи. Медленный и нестабильный pipeline, который команда игнорирует, превращается в формальность.

Что должно храниться в репозитории

• конфигурация workflow или pipeline;

• скрипты установки, тестирования, сборки и миграций;

• описание требуемых версий и зависимостей;

• конфигурация инфраструктуры, если применяется IaC;

• правила качества и безопасности;

• инструкция по ручному запуску, откату и аварийной остановке.

Секреты в репозиторий не добавляют. Храните их в предназначенном для этого механизме платформы или внешнем менеджере секретов и выдавайте минимально необходимые права.

Как внедрить CI/CD по шагам

1. Сделайте локальную сборку воспроизводимой. Новый участник должен собрать и проверить проект по документированной команде.

2. Добавьте быстрый CI. Начните с линтера и критичных тестов на pull request.

3. Запретите слияние при обязательной красной проверке. Исключения должны быть видимыми и редкими.

4. Собирайте один артефакт. Продвигайте одну и ту же версию через окружения, не пересобирайте её перед production.

5. Создайте staging. Сделайте его достаточно похожим на production для значимых проверок.

6. Автоматизируйте delivery. Подготовьте релиз и оставьте ручное подтверждение, пока процесс не станет устойчивым.

7. Добавьте наблюдаемость и откат. До автоматического deployment команда должна понимать, как заметить и остановить плохой релиз.

8. Улучшайте узкие места. Разделяйте тесты, используйте безопасный кэш и устраняйте нестабильные проверки.

Как выбрать CI/CD-систему

Если репозиторий уже находится на GitHub или GitLab, встроенный инструмент часто даёт самый короткий путь. Self-hosted решение оправдано требованиями к сети, данным, средам выполнения или контролю, но добавляет обновления и обслуживание.

Безопасность pipeline

• не запускайте недоверенный код с production-секретами;

• разделяйте права CI и деплоя по окружениям;

• закрепляйте внешние actions и зависимости на проверенных версиях;

• проверяйте изменения файлов pipeline через code review;

• используйте короткоживущие учётные данные, где это возможно;

• не выводите токены и переменные в лог;

• подписывайте и идентифицируйте выпускаемые артефакты;

• храните журнал того, кто и что развернул.

Официальная справка GitHub по workflow syntax отдельно рекомендует указывать версию используемого action; ссылка на меняющуюся ветку может неожиданно изменить поведение сборки.

Типичные ошибки

• добавлять деплой до воспроизводимой сборки и тестов;

• считать зелёный pipeline доказательством отсутствия дефектов;

• пересобирать артефакт отдельно для каждого окружения;

• хранить секреты в YAML или образе;

• запускать все тяжёлые проверки для каждого небольшого изменения;

• игнорировать нестабильные тесты;

• разрешать deploy job слишком широкие права;

• не иметь health-check, мониторинга и процедуры отката;

• копировать чужой YAML без понимания команд и модели угроз.

Чек-лист готовности

• проект собирается в чистой среде;

• обязательные проверки дают полезную и быструю обратную связь;

• ошибка блокирует продвижение версии;

• артефакт имеет уникальный идентификатор;

• секреты отделены от кода и логов;

• staging использует тот же артефакт, что и production;

• права деплоя ограничены;

• есть наблюдение после релиза;

• откат описан и проверен;

• ответственный понимает, как остановить pipeline.

Вывод

CI/CD начинается не с выбора сервиса, а с короткой и воспроизводимой проверки каждого изменения. Сначала автоматизируйте сборку и тесты, затем создайте версионируемый артефакт, delivery до staging, контролируемый production-релиз и откат. Такой путь даёт пользу постепенно и не превращает YAML в скрытую инфраструктуру, которую никто не умеет обслуживать.