[Документация Yandex Cloud](../index.md) > [Облачная терминология](index.md) > Управление проектами и задачами > CI/CD

# CI/CD

_CI/CD_ (Continuous Integration / Continuous Delivery — непрерывная интеграция и непрерывная доставка/развертывание) — это набор практик и инструментов, которые позволяют разработчикам часто и с минимальным количеством ошибок обновлять код, автоматически тестировать его и доставлять изменения в среду эксплуатации. Это основа современной разработки ПО и ключевой элемент [DevOps](*popup-1).

До появления CI/CD разработчики могли неделями или месяцами готовить релиз и только в конце интегрировать весь новый код сразу в одну большую ветку. Это приводило к огромному количеству конфликтов и ошибок, которые команде необходимо было оперативно исправлять. Конец каждого цикла сопровождался стрессом и переработками.

Подход CI/CD значительно повысил качество продуктов, сократил время выпуска релизов и облегчил работу разработчикам. Из долгой изолированной разработки с производственным завалом в конце цикла процесс превратился в непрерывный, автоматизированный и прогнозируемый.

## Что такое CI (Continuous Integration) {#ci}

_Непрерывная интеграция (CI)_ — частое объединение небольших изменений кода в одну основную ветку. Каждая итерация автоматически запускает сборку и тестирование.

Основные принципы CI:

* частые коммиты в общую ветку репозитория — несколько раз в день;
* автоматический запуск сборок и тестов;
* быстрое обнаружение и исправление ошибок — до того, как они накопятся.

## Что такое CD (Continuous Delivery и Continuous Deployment) {#cd}

Аббревиатура CD может означать два разных понятия:

* _Continuous Delivery (непрерывная доставка)_ — подход, при котором разработка происходит короткими циклами, а код всегда готов к релизу. В таких системах запуск финального развертывания в среду эксплуатации всегда выполняет человек.

* _Continuous Deployment (непрерывное развертывание)_ — более автоматизированный подход, при котором изменения после успешных тестов попадают в среду эксплуатации без подтверждения разработчика.

#|
|| **Характеристика** | **Continuous Delivery** | **Continuous Deployment** ||
|| Развертывание | Вручную | Автоматически ||
|| Контроль релиза | Команда решает, когда выпускать | Выпуск происходит при каждом успешном коммите ||
|| Риск | Оценивается разработчиком | Разработчик полагается на качество автоматических проверок ||
|| Сложность внедрения | Средняя | Высокая ||
|| Кому подходит | Большинство компаний с регулируемыми релизами | Зрелые компании с продвинутой культурой тестирования ||
|#

Среди задач, которые относятся к CD-разработке:

* сборка артефактов — компиляция кода и упаковка в образы или пакеты;
* автоматическое тестирование — юнит-тесты, интеграционные и нагрузочные тесты;
* развертывание в тестовые среды — проверка в условиях, близких к среде эксплуатации;
* развертывание в среду эксплуатации — автоматическое или с ручным подтверждением;
* мониторинг и откат — отслеживание метрик и возврат к предыдущей версии при сбое.

## Как работает CI/CD: типичный пайплайн {#pipeline}

Типичный CI/CD-[пайплайн](*popup-2) выглядит так:

![ci-cd-scheme](../_assets/glossary/ci-cd.svg)

1. Разработчик пишет код, с помощью [системы контроля версий](vcs.md) делает коммит в репозиторий и открывает пул-реквест.
1. CI-система автоматически запускает сборку и тесты. Также в проекте может быть настроена [контейнеризация](containerization.md).
1. Разработчик получает результаты сборки и тестов (модульные, нагрузочные и интеграционные тесты). Если обнаружатся ошибки, то после внесения правок цикл повторяется.
1. После успешного прохождения тестов и ревью от коллег новый код вливается в основную ветку.
1. CD-система собирает артефакт и развертывает его в тестовую среду.
1. В тестовой среде выполняются дополнительные проверки: [smoke-тесты](https://ru.wikipedia.org/wiki/Smoke_test), ручное тестирование и другое.
1. После успешной проверки в тестовой среде код развертывается в среду эксплуатации — либо автоматически (непрерывное развертывание), либо после ручного одобрения (непрерывная доставка).
1. После развертывания в среду эксплуатации система мониторинга (например, [Yandex Monitoring](https://yandex.cloud/ru-kz/services/monitoring/) и [Yandex Monium](https://yandex.cloud/ru-kz/services/monium)) отслеживает метрики производительности, ошибки и поведение пользователей. При возникновении аномалий можно быстро вернуться на предыдущую стабильную версию.

Также код и в процессе CI, и в процессе CD должен проверяться на безопасность: статистический анализ (SAST), поиск секретов в коде, поиск уязвимостей в зависимостях, контроль используемых лицензий.

Автоматизация большинства шагов — ключевое условие. Ручные операции замедляют процесс и вносят непредсказуемость.

## Преимущества CI/CD {#advantages}

Переход на CI/CD следующим образом улучшает процесс разработки:

* **Ускорение релизов** — автоматизация помогает выпускать обновления за часы, а не за недели.
* **Раннее обнаружение ошибок** — тесты запускаются при каждом коммите. Баг, найденный сразу, дешевле исправить, чем обнаруженный перед релизом.
* **Снижение рисков** — небольшие и частые изменения проще откатить, чем крупный релиз раз в квартал.
* **Прозрачность** — каждый участник команды видит статус сборки, результаты тестов и историю развертываний.
* **Экономия ресурсов** — автоматика заменяет рутинные ручные операции, разработчики могут заниматься непосредственно кодом и новыми фичами.
* **Улучшение взаимодействия** — разработчики, тестировщики и DevOps-инженеры работают с единым пайплайном и прозрачным процессом.

По данным [DevOps Research and Assessment](https://dora.dev/research/), команды с развитыми практиками CI/CD в 208 раз чаще выпускают изменения и в 2 604 раза быстрее восстанавливаются после сбоев, чем команды с низким уровнем внедрения практик DevOps.

## Возможные сложности {#challenges}

CI/CD можно смело рекомендовать любой команде, однако иногда внедрение может сопровождаться дополнительными сложностями:

* **Начальные затраты** — настройка пайплайна, выбор инструментов и обучение команды требуют времени и усилий.
* **Культурные изменения** — CI/CD — это не только инструменты, но и изменение процессов. Команда должна принять практику частых коммитов и доверять автоматике.
* **Legacy-системы** — старые монолитные приложения сложно покрыть тестами и автоматизировать их развертывание.
* **Качество тестов** — надежность пайплайнов напрямую зависит от надежности тестов. Ложные срабатывания и низкое покрытие снижают ценность автоматизации.
* **Риски Continuous Deployment** — полная автоматизация развертывания требует зрелой тестовой базы. Без нее баги могут попасть в среду эксплуатации незамеченными.
* **Зависимость от инфраструктуры** — нестабильная CI/CD-система может замедлить разработку сильнее, чем ее отсутствие.

## CI/CD в Yandex Cloud {#ci-cd-yc}

Yandex Cloud предоставляет следующие инструменты для построения CI/CD-пайплайнов любой сложности:

* [SourceCraft](https://sourcecraft.dev) — платформа для совместной разработки со встроенными инструментами CI/CD, управлением репозиториями, код-ревью и сканерами безопасности. Подробнее в [документации](https://sourcecraft.dev/portal/docs/ru).
* [Yandex Managed Service for GitLab](https://yandex.cloud/ru-kz/services/managed-gitlab/) — управляемый сервис на базе GitLab, позволяющий настроить полный CI/CD-пайплайн. Подробнее в [документации](../managed-gitlab/index.md).
* Хранилища артефактов сборки:

  * [Yandex Cloud Registry](https://yandex.cloud/ru-kz/services/cloud-registry/) — универсальное хранилище артефактов разработки: Docker-образы, Helm-чарты, Node.js, Python, Java, бинарные файлы и другие типы. Подробнее в [документации](../cloud-registry/index.md).
  * [Yandex Container Registry](https://yandex.cloud/ru-kz/services/container-registry/) — хранилище Docker-образов и Helm-чартов. Включает встроенный сканер уязвимостей для образов. Подробнее в [документации](../container-registry/index.md).
  * [Yandex Object Storage](https://yandex.cloud/ru-kz/services/storage/) — объектное хранилище для артефактов произвольного формата: архивов сборок, бинарных файлов, отчетов тестов и других файлов. Подробнее в [документации](../storage/index.md).

* Системы мониторинга:

  * [Yandex Monium](https://yandex.cloud/ru-kz/services/monium/) — платформа для сбора, хранения и анализа телеметрии: метрик, логов и трейсов. Позволяет отслеживать состояние сервисов после развертывания, настраивать алерты и расследовать инциденты. Подробнее в [документации](../monium/index.md).
  * [Yandex Monitoring](https://yandex.cloud/ru-kz/services/monitoring/) — сервис позволяет собирать и хранить метрики, а также отображать их в виде графиков на дашбордах. Подробнее в [документации](../monitoring/index.md).

* Безопасность CI/CD:

  * [Yandex Security Deck](https://yandex.cloud/ru-kz/services/security-deck/) — комплексный CNAPP-сервис. В контексте CI/CD полезны следующие модули:
    * [Kubernetes® Security Posture Management (KSPM)](../security-deck/concepts/kspm.md) — контроль безопасности конфигурации кластеров Kubernetes.
    * [Управление уязвимостями](../security-deck/concepts/vulnerability-management.md) — обнаружение уязвимостей в облачной инфраструктуре.
  * Сканирование образов в [Yandex Container Registry](../container-registry/concepts/vulnerability-scanner.md) — автоматическая проверка Docker-образов на уязвимости при загрузке или по расписанию.
  * Встроенные [сканеры безопасности](https://sourcecraft.dev/portal/docs/ru/sourcecraft/security/security-overview) в SourceCraft: сканирование секретов, анализ зависимостей, статический анализ кода, анализ уязвимостей с помощью ИИ и история сканирований.

#### Полезные материалы {#see-also}

* [Вебинар «CI/CD в Облаке с помощью GitLab»](https://www.youtube.com/watch?v=Ngadh9T2dOI)
* [Курс DevSecOps от Yandex Cloud](https://yandex.cloud/ru/training/devsecops)
* [Руководство по настройке CI/CD между Yandex Cloud Functions и GitHub](../tutorials/serverless/ci-cd-github-functions.md)

[*popup-1]: [_DevOps_](https://ru.wikipedia.org/wiki/DevOps) — совокупность методов, процедур и инструментов, которые помогают командам быстро и качественно разрабатывать, тестировать и развертывать приложения.

[*popup-2]: _Пайплайн_ — это последовательность автоматических шагов, которые код проходит от попадания в репозиторий до среды эксплуатации.