---
title: CI/CD
questionDates:
  q-transfer-0406: '2026-10-01'
  q-transfer-0407: '2026-10-01'
  q-transfer-0423: '2026-10-01'
seo:
  description: >-
    Тема «CI/CD» для собеседования DevOps. Как доставлять один и тот же build по
    окружениям? Чем Continuous Delivery отличается от Continuous Deployment?
  title: CI/CD — DevOps
---

[Все темы DevOps](/prep/devops)

## Как доставлять один и тот же build по окружениям? [#q-transfer-0406]

Артефакт собирают один раз из конкретного commit, присваивают неизменяемую версию и публикуют в registry вместе с checksum или digest. В test, staging и production продвигают именно этот digest, а конфигурацию, секреты и параметры окружения подают отдельно. Pipeline фиксирует, где артефакт прошёл тесты и кто разрешил promotion. Повторная сборка даже из того же исходного кода может дать другой результат из-за зависимостей и инструментов, поэтому она ломает доказанную цепочку. Rollback выбирает ранее проверенную версию; миграции данных должны иметь отдельный совместимый план возврата.

:::note[Ссылки для изучения]

1. [Один артефакт для всех окружений: сборка, отдельная конфигурация и хранение версий](https://www.jetbrains.com/ru-ru/teamcity/ci-cd-guide/ci-cd-best-practices/)
   :::

---

## Чем Continuous Delivery отличается от Continuous Deployment? [#q-transfer-0407]

Continuous Delivery автоматизирует сборку, проверки и подготовку релизного артефакта так, что его можно безопасно выпустить по решению человека или бизнеса. Continuous Deployment идёт дальше: каждое изменение, прошедшее pipeline, автоматически попадает в production. Ручной gate не обязательно делает процесс плохим, если он нужен для регуляторного окна, координации или бизнес-решения и не скрывает ручное тестирование. Для автоматического deployment нужны сильные проверки, наблюдаемость, постепенный rollout и быстрый rollback. Термины часто смешивают, поэтому в команде лучше явно описать, где находится последнее ручное решение.

:::note[Ссылки для изучения]

1. [Continuous Delivery и Continuous Deployment: ручное решение о релизе или автоматический выпуск](https://www.jetbrains.com/ru-ru/teamcity/ci-cd-guide/continuous-deployment/)
   :::

---

## Какие стадии нужны в CI/CD pipeline? [#q-transfer-0423]

Pipeline обычно проверяет исходный код, собирает один версионированный артефакт, запускает unit, интеграционные и security-проверки, затем публикует артефакт в registry. Следующие стадии продвигают тот же digest в среду, выполняют миграции по отдельному плану, deploy и smoke или health-проверки. Независимые проверки запускают параллельно, зависимые связывают явно и останавливают ранним fail-fast. Для production нужны gate по политике, постепенный rollout, мониторинг и проверенный rollback. Каждая стадия передаёт версию и доказательства дальше, чтобы нельзя было случайно развернуть непроверенную пересборку.

:::note[Ссылки для изучения]

1. [Стадии CI/CD pipeline: сборка, последовательные проверки, тестовые среды и релиз](https://www.jetbrains.com/ru-ru/teamcity/ci-cd-guide/ci-cd-pipeline/)
2. [Сборка и автоматические проверки в CI. Артём Шумейко, с 2:11](https://www.youtube.com/watch?v=pFKwmEdwZZQ&t=131s)

:::