CI/CD (Continuous Integration / Continuous Delivery или Deployment) — это набор практик и принципов разработки программного обеспечения, направленных на автоматизацию и ускорение процессов сборки, тестирования, доставки и развёртывания приложений. Он помогает командам быстрее и надёжнее выпускать программный продукт, улучшая его качество и снижая риски, связанные с интеграцией изменений.

1. CI (Continuous Integration) — непрерывная интеграция

CI означает регулярное слияние кода от всех разработчиков в общую ветку (обычно main/master) с последующей автоматической сборкой и тестированием. Основные цели — быстро находить ошибки, минимизировать конфликт изменений и повышать стабильность.

Основные шаги CI:

• Разработчик делает коммит и пушит изменения в репозиторий.

• Триггерится CI-пайплайн:

  • Код собирается (build).

  • Выполняются юнит-тесты.

  • Производится анализ качества кода (lint, static analysis).

  • При необходимости — запускаются интеграционные и e2e тесты.

• Если что-то не прошло — CI падает, и коммит считается "сломавшим" пайплайн.

Инструменты CI:

• GitHub Actions

• GitLab CI

• Jenkins

• Travis CI

• CircleCI

• Bitbucket Pipelines

Преимущества CI:

• Быстрая обратная связь.

• Быстрое обнаружение багов.

• Автоматизированная проверка качества кода.

• Меньше конфликтов между ветками и разработчиками.

2. CD (Continuous Delivery) — непрерывная доставка

CD в контексте Continuous Delivery означает автоматическую подготовку кода к развёртыванию. Это следующий шаг после CI — изменения, прошедшие тестирование, автоматически подготавливаются к публикации (но не публикуются без подтверждения).

Что делает система доставки:

• Забирает артефакты (например, .jar, .zip, .docker image), полученные на стадии CI.

• Разворачивает их на staging-окружение.

• Запускает дополнительные тесты (smoke, UI-тесты).

• Подготавливает деплой на продакшен: через кнопку, скрипт или автоматический триггер.

• Сохраняет стабильность — не деплоит, если тесты не прошли.

Цель Continuous Delivery:

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

3. CD (Continuous Deployment) — непрерывное развёртывание

Если в Continuous Delivery код доставляется, но финальный шаг требует ручного подтверждения, то в Continuous Deployment он полностью автоматизирован — всё, что прошло тесты, автоматически разворачивается в продакшен без участия человека.

Процесс CD:

• После успешного CI:

  • Приложение деплоится на staging.

  • Если все проверки прошли — сразу деплоится на production.

  • Включаются health checks, canary deployments, мониторинг.

Когда это применимо:

• Высокий уровень автоматизации.

• Надёжные тесты.

• Минимальный риск сбоев (или возможность быстро откатиться).

• Небольшие, частые релизы.

4. Разница между Continuous Delivery и Continuous Deployment

Характеристика	Continuous Delivery	Continuous Deployment
Деплой на продакшен	По запросу (manual)	Автоматически
---	---	---
Уровень автоматизации	Высокий, но с ручным шагом	Полная автоматизация
---	---	---
Контроль релизов	Больше	Меньше (но быстрее и чаще)
---	---	---
Подходит для	Большинства команд	Команд с высокой зрелостью CI/CD
---	---	---

5. CI/CD pipeline — как выглядит полный процесс

[Код → Git push]

↓

[CI: Сборка, Тесты, Анализ кода]

↓

[CD: Сборка артефакта, Deploy на Staging]

↓

[Auto-тесты на Staging]

↓

[Deploy на Production]

Каждый шаг можно расширить:

• Добавить уведомления (Slack, Telegram).

• Вести логирование и мониторинг.

• Делать canary deployments или blue/green deployments.

6. CI/CD и DevOps

CI/CD — важнейший компонент философии DevOps, объединяющей разработку и эксплуатацию. Она предполагает:

• Автоматизацию жизненного цикла ПО.

• Инфраструктуру как код (IaC).

• Мониторинг и обратную связь после деплоя.

CI/CD делает релизы более частыми, предсказуемыми и менее рискованными.

7. Что можно автоматизировать в CI/CD

• Проверка форматирования и линтинга.

• Тесты всех уровней.

• Сборка приложений (iOS, Android, Docker).

• Сканирование зависимостей (безопасность).

• Деплой в Kubernetes / облако / сервер.

• Rollback / откат в случае ошибок.

• Сбор метрик и алерты.

8. Проблемы при внедрении CI/CD

• Нестабильные тесты (flaky tests).

• Долгие пайплайны → медленная обратная связь.

• Сложные окружения (несовместимость staging/prod).

• Отсутствие культуры "малых изменений".

• Отказ от CI/CD → медленные релизы, баги на проде.

9. Практики хорошего CI/CD

• Мержить в main только через pull-request с проверками.

• Поддерживать высокий процент тестов.

• Минимизировать время сборки.

• Делать small, incremental changes.

• Настроить мониторинг после деплоя.

• Обеспечить катастрофоустойчивость (канарейки, откаты, фича-флаги).

10. Примеры из практики

• GitHub Actions → собирает, тестирует, деплоит Docker образ на AWS.

• GitLab CI → с триггерами для staging и production с ручным подтверждением.

• Jenkins + Spinnaker → продвинутый деплой в Kubernetes с автоскейлингом и rollout’ом.

CI/CD — это не просто автоматизация, это культура: коммит → проверка → релиз → уверенность.