CI/CD (Continuous Integration / Continuous Delivery or Deployment) — набор практик разработки, автоматизирующих путь кода от коммита разработчика до production-среды. CI/CD-пайплайн — последовательность автоматических шагов: сборка → тесты → анализ кода → публикация артефакта → деплой. Позволяет командам выпускать изменения несколько раз в день, а не раз в квартал.
CI — Continuous Integration
Continuous Integration — практика, при которой каждый коммит в репозиторий автоматически запускает:
- Сборку приложения (build)
- Юнит-тесты и интеграционные тесты
- Статический анализ кода (линтеры, SAST — Static Application Security Testing)
- Генерацию отчёта о покрытии кода
Цель CI — обнаружить ошибки в течение минут после коммита, пока разработчик ещё в контексте задачи, а не через неделю при слиянии feature-ветки.
CD — Continuous Delivery vs Continuous Deployment
Continuous Delivery — каждый успешный CI-пайплайн создаёт артефакт (Docker-образ, RPM-пакет, архив), готовый к деплою в production. Деплой требует ручного одобрения (approval gate) — одного клика ответственного.
Continuous Deployment — полная автоматизация: успешный CI-пайплайн автоматически деплоит в production без ручного вмешательства. Используется в зрелых командах с высоким тестовым покрытием (>80%) и надёжной возможностью отката.
История
Концепцию Continuous Integration предложил Грэди Буч (Grady Booch) в 1991 году, развил Кент Бек (Kent Beck) в XP (Extreme Programming) в 1999 году. CruiseControl — первый CI-сервер — появился в 2001 году. Hudson (2004, затем Jenkins в 2011 году) стал самым популярным open-source CI. Travis CI (2011) первым предложил CI как облачный сервис. GitHub Actions (2018) сделал CI/CD нативным для GitHub. К 2023 году GitHub Actions занимает более 50% рынка CI/CD по количеству активных пайплайнов.
Платформы CI/CD
- GitLab CI/CD — встроен в GitLab, runner на собственных серверах или shared; бесплатно 400 мин/мес
- Bitbucket Pipelines — CI/CD для Atlassian-экосистемы; бесплатно 50 мин/мес
- GitHub Actions — нативный CI/CD для GitHub; бесплатно 2000 мин/мес для публичных репо
- Jenkins — классический open-source CI, полная гибкость, высокий порог входа
- TeamCity — enterprise CI от JetBrains, бесплатно для 100 build configurations
CI/CD и хостинг
Для деплоя на VPS или выделенный сервер типичные шаги пайплайна: сборка Docker-образа → публикация в Container Registry → SSH-подключение к серверу → docker pull + docker-compose up -d. Возможность отката к предыдущей версии — обязательное требование для production-пайплайна: без неё инцидент превращается в многочасовое восстановление. Staging-среда в CI/CD-пайплайне разворачивается автоматически при каждом merge в main, production — только по ручному одобрению.
Метрики DORA для оценки DevOps-зрелости
DORA (DevOps Research and Assessment) определяет четыре ключевые метрики CI/CD: Deployment Frequency (частота деплоев), Lead Time for Changes (время от коммита до production), Change Failure Rate (доля деплоев, вызвавших инциденты), Time to Restore Service (время восстановления). Организации уровня Elite деплоят несколько раз в день с Lead Time менее 1 часа и Change Failure Rate менее 5%.
Безопасность CI/CD-пайплайна
Критичные практики безопасности при деплое:
- Хранить SSH-ключи и токены в Secrets хранилище CI-системы (GitLab Variables, GitHub Secrets), а не в репозитории
- Использовать минимально необходимые права для deploy-пользователя на сервере: только перезапуск сервиса и копирование файлов в целевую директорию
- Подписывать Docker-образы и проверять подпись перед деплоем
- Сканировать образы на уязвимости (Trivy, Clair) как шаг пайплайна