CI/CD

Три разные практики

• Continuous Integration (CI) — изменения регулярно объединяются в общую ветку и автоматически проверяются. Цель — быстро обнаружить несовместимость и не накапливать большие непроверенные изменения.
• Continuous Delivery — система постоянно находится в состоянии, пригодном для безопасного выпуска по требованию. Релиз на production может требовать явного решения человека.
• Continuous Deployment — каждое изменение, прошедшее установленные проверки, автоматически отправляется пользователям. Это более строгий режим, который не обязателен для continuous delivery.

Continuous delivery не означает «деплоить всё подряд». Напротив, практика требует надёжных проверок, управляемых изменений и возможности быстро прекратить проблемный выпуск.

Конвейер поставки

Commit / pull request
  → lint и unit tests
  → сборка неизменяемого артефакта
  → интеграционные проверки
  → staging и проверка сценариев
  → approval при необходимости
  → production
  → post-deploy checks и наблюдение

Артефакт собирается один раз и продвигается между окружениями. Пересборка production-версии из другого состояния репозитория нарушает воспроизводимость: проверялся один набор файлов, а выпускается другой.

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

Проверки и управление риском

• автоматические тесты и статический анализ;
• security- и dependency checks;
• сборка и проверка артефакта;
• миграции на копии репрезентативных данных;
• smoke tests после выпуска;
• synthetic checks ключевых сценариев;
• наблюдение за ошибками, задержкой и бюджетом ошибок.

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

Rollback и roll forward

Откат — это заранее проверенный способ вернуть работающее состояние, а не загрузка старых файлов вручную. Для него нужно учитывать:

• совместимость старого кода с новой схемой БД;
• неизменяемость и доступность предыдущего артефакта;
• сохранность данных, созданных после релиза;
• конфигурацию и миграции, которые нельзя просто отменить.

Иногда безопаснее выпустить небольшое исправление вперёд. Выбор зависит от данных и последствий, а не от наличия кнопки rollback в CI.

Типовые ошибки

• Continuous deployment выдаётся за continuous delivery.
• Деплой идёт из рабочей директории разработчика или по FTP без версии выпуска.
• Production собирается заново и отличается от проверенного артефакта.
• Миграция БД делает откат невозможным.
• Проверки есть, но команда продолжает выпускать при красном конвейере.
• После деплоя нет наблюдения за пользовательскими сценариями.

Связанные инструменты

• GitHub Actions — workflows, environments и deployment protection.
• GitLab CI/CD — pipelines, jobs, rules и environments.
• Docker — воспроизводимые образы приложения.
• Argo CD — доставка желаемого состояния в Kubernetes по GitOps.

Связанные материалы

• Окружения — promotion между local, staging и production.
• CI/CD для WordPress — прикладной пример.
• Метрики Delivery и DORA — измерение скорости и последствий поставки.
• Alerting — сигнал после выпуска.

Материалы и источники

• DORA: Continuous integration — практики и ошибки непрерывной интеграции.
• DORA: Continuous delivery — отличие от continuous deployment и состав практик.
• DORA: Deployment automation — автоматизация выпуска и снижение ручного вмешательства.