CI/CD (Continuous Integration / Continuous Delivery) — инженерная практика, которая меняет не только процесс разработки, но и форму требований: критерии приёмки должны быть автоматизируемы, НФТ деплоя и observability становятся обязательными, а граница «готово» привязана к стадиям конвейера. Для системного аналитика понимание пайплайна — не DevOps-специализация, а способ писать реализуемые и проверяемые спецификации. Культурный и процессный контекст DevOps — в 05.04 DevOps и непрерывная поставка — влияние на анализ; здесь — техническая модель конвейера и шаблоны того, что закладывать в требования.

1. Суть темы

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

ПрактикаСутьВлияние на «Definition of Done»
Continuous Integration (CI)Каждый merge в общую ветку проходит сборку и автотестыDoD = код прошёл CI на целевой ветке
Continuous Delivery (CDelivery)Артефакт всегда готов к релизу; prod — по ручному решению утверждающего по RACIDoD = успешный деплой на staging + чек-лист sign-off перед prod
Continuous Deployment (CDeployment)После успешной приёмки на staging пайплайн автоматически выкатывает на prod (часто через canary)DoD = успешный prod-деплой + post-deploy проверки

Observability (логи, метрики, health checks) нужна при любом уровне CD, не только при полном автодеплое: staging-приёмка, rollback и ручной релиз тоже требуют обратной связи от системы.

flowchart LR
    subgraph CI [Continuous Integration]
        A[Коммит / PR] --> B[Сборка]
        B --> C[Unit / Integration / Contract tests]
        C --> D{Quality gates}
    end
    D -- Нет --> J[Уведомление dev / QA / аналитика]
    D -- Да --> E[Публикация артефакта]
    E --> F[Deploy на staging]
    F --> K[Миграции БД / E2E / smoke]
    K --> L{Staging OK?}
    L -- Нет --> J
    L -- Да --> G{Режим релиза}
    G -->|Delivery: ручной sign-off| H[Deploy на prod]
    G -->|Deployment: canary / auto| H
    H --> M[Post-deploy smoke / мониторинг]

Рис. Конвейер: CI → артефакт → staging → prod. Staging обязателен для обеих моделей; различие — только в том, кто инициирует prod после успешной приёмки на staging (ручной sign-off при Delivery или автоматика при Deployment).

Аналитик не проектирует Jenkins/GitLab CI, но отвечает за содержание quality gates и критерии готовности на каждой стадии.

2. Ключевые понятия

2.1 Стадии конвейера и зона ответственности

СтадияЧто происходитАналитикQA / dev
Source / BuildКоммит, сборка артефактаID требования в ветке/коммите; трассировкаНастройка триггеров, сборки
Static Analysis / SecuritySAST, dependency scan, сканеры секретовПороги блокировки как НФТ качества (→ 02.04.03 Управление качеством требований, 08.07 Основы кибербезопасности для системного аналитика)Инструменты, правила
Unit / Integration / ContractМодульные, интеграционные и контрактные проверкиКонтракты API, схемы данных для contract tests (→ 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf))Реализация и поддержка тестов
Performance / Load gateНагрузочный или perf-smoke прогон на stagingПороги latency, throughput, error rate как НФТ (→ 08.02 Нефункциональные требования (НФТ) — классификация и стандарты)Сценарии нагрузки, инфраструктура
Acceptance / E2EBDD, сквозные сценарииAC в Gherkin, рецензия E2E на соответствие бизнес-правилам (→ 02.04.02 Критерии приёмки (Acceptance Criteria), 02.04.01 Верификация и валидация (V&V))Автоматизация сценариев
DB MigrationПрименение миграций на staging / prodBackward-compatible схема, порядок «схема → код», rollback миграции (→ 03.03.02 Логическая и физическая модель данных)Скрипты, оркестрация в пайплайне
Deploy (staging → prod)Blue-Green, Canary, RollingНФТ деплоя, rollback, фича-флаги (→ 10.01.12 Шаблон нефункциональных требований (NFR))Стратегия и оркестрация (→ 07.08 Контейнеризация и оркестрация (Docker, Kubernetes))
Manual approval gateРучная пауза перед prod (Delivery)Кто утверждает, где фиксируется (тикет, release note), SLA ожиданияНастройка gate в пайплайне
Post-deploy smokeБыстрая проверка после выкладки на prodСписок критичных сценариев и пороги «красного» деплояАвтоматизация smoke-тестов
MonitoringМетрики, алерты, логиБизнес-события и метрики в спецификацииИнфраструктура observability

2.2 Требования к средам (environments)

Конвейер опирается на цепочку сред; каждая должна быть описана в требованиях:

СредаНазначениеЧто фиксирует аналитик
devЛокальная и ранняя интеграцияМинимальный набор тестовых данных, mock-контракты
test / CIАвтопрогоны в пайплайнеИзолированные фикстуры, без prod-PII (→ 08.06 Юридические и регуляторные требования РФ (PCI-DSS))
stagingПриёмка перед prod; feature parity с prodНабор данных для E2E, сценарии sign-off; маскирование или синтетика вместо prod-PII при prod-like объёме (→ 08.06 Юридические и регуляторные требования РФ (PCI-DSS))
prodБоевая эксплуатация«Не тестируем на prod»; canary/rollback-критерии

Feature parity между staging и prod — явное требование: иначе приёмка на staging не предсказывает поведение в бою. Данные на staging могут быть синтетическими, но объём и профиль нагрузки должны позволять perf-gate и E2E, релевантные prod.

2.3 Quality gates как числовые НФТ

Quality gates — пороги, при нарушении которых пайплайн блокирует релиз. Аналитик согласует их с командой и фиксирует в спецификации:

  • Покрытие кода тестами ≥ X % (или покрытие критичных модулей).
  • Zero critical/high уязвимостей в SAST/dependency scan.
  • Все acceptance-сценарии зелёные на staging.
  • Contract tests пройдены для затронутых API.
  • Perf/load gate: p95 latency ≤ X мс, error rate ≤ Y % на согласованном профиле нагрузки.

Споры «релиз заблокирован Sonar» решаются заранее: пороги — часть 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, а не «настройка DevOps».

2.4 Delivery vs Deployment: матрица sign-off

РежимКто утверждает prodDoD для storyЧек-лист аналитика
DeliveryУтверждающий по RACI: PO, release manager или аналитик — фиксируйте в release policyУспешный staging + sign-offРегрессия на staging, rollback-plan, коммуникация stakeholders, manual approval gate
DeploymentАвтоматика (при зелёном пайплайне и canary-критериях)Успешный prod + post-deploy smokeCanary-критерии, автооткат по метрикам, фича-флаг для поэтапного включения

DoD «все стадии конвейера без ошибок» всегда уточняйте: до какой среды (staging или prod) и нужен ли ручной sign-off.

Регуляторные и экстренные релизы вне штатного CD — через 02.05.02 Управление изменениями (Change Control Board); routine CD — quality gates и sign-off по согласованному RACI (подробнее о процессе — 05.04 DevOps и непрерывная поставка — влияние на анализ).

3. Как применяется в работе аналитика

3.1 Требования к тестируемости

CI требует автоматизируемых критериев приёмки. В спецификации закладывайте:

  • Поведение в формате BDD (Gherkin): Given-When-Then без двусмысленностей.
  • Тестовые интерфейсы: API для инициализации состояния и сброса данных.
  • Атомарность сценариев: каждый тест изолирован.
  • Тестовые данные: фикстуры, возможность быстрого восстановления; запрет prod-PII в автопрогонах.
  • Стабильность E2E: сценарии детерминированы — без «случайных» данных, внешних таймаутов без порога и недетерминированных AC; flaky-сценарии помечаются и выводятся из blocking gate до стабилизации.

Пример критерия с учётом синхронного API и асинхронного события (→ 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events)):

Сценарий: Отмена заказа в статусе «Новый»
Дано: в системе существует заказ №123 в статусе «Новый»
Когда: выполняется POST /orders/123/cancel
Тогда: статус заказа — «Отменён»
И: в течение 5 с в топик orders.events публикуется событие OrderCancelled с orderId: 123

Отдельно укажите в требованиях: проверка события — через test consumer или polling; timeout и retry — с явными порогами, чтобы E2E не был flaky.

3.2 НФТ развёртывания, миграции и версии API

Помимо времени деплоя и стратегии (Blue-Green, Canary, Rolling), закладывайте:

  • Zero-downtime и миграции БД: backward-compatible изменения схемы; порядок «сначала схема → потом код» или expand-contract; миграция как отдельный шаг пайплайна на staging до E2E (→ 03.03.02 Логическая и физическая модель данных, 07.01 Базы данных и SQL на уровне аналитика).
  • Rollback: время восстановления, условия автоматического отката (порог ошибок, latency, падение бизнес-метрик).
  • Идемпотентность деплоя: повторный прогон пайплайна безопасен (re-run без дублирования side effects).
  • Версионирование API: breaking change запрещён без major-версии; contract tests в CI (→ 03.05.07 Управление версионированием API и жизненным циклом).
  • Post-deploy smoke: перечень критичных проверок сразу после prod-deploy — в требованиях, не только в runbook QA.
  • Performance gate: пороги на staging перед prod (см. раздел 2.3).
  • Конфигурация: параметры вынесены из кода, инжектируются на деплое (12-factor app — см. источники).

3.3 Фича-флаги

Помимо управления и срока жизни флага, опишите оба состояния:

  • Поведение при off: fallback UX, совместимость API, отсутствие частично включённой логики.
  • Тестирование в пайплайне: E2E для on и off; canary-процент как отдельный параметр.
  • Стандарт описания: OpenFeature (→ источники).

3.4 Observability

Требования к обратной связи нужны для staging (приёмка, rollback) и prod (мониторинг релиза):

  • Структурированное логирование: бизнес-события в JSON с ID сущностей и trace-id.
  • Бизнес-метрики: счётчики успехов/ошибок, latency, размеры очередей.
  • Health Check: эндпоинты /health, /ready для оркестратора.

3.5 Трассировка и docs-as-code в конвейере

ID требования (Jira, YouTrack) — в ветках, коммитах, названиях тестов. Это продолжение 02.03.04 Трассировка требований (концепция) и 07.05 Системы контроля версий (Git) для документации; матрицу оформляйте по 10.01.15 Шаблон матрицы трассировки.

Документация аналитика проходит тот же Git-конвейер. В требованиях к docs-pipeline зафиксируйте:

  • Lint и link-check для Markdown/OpenAPI — blocking gate до merge.
  • Review gate: минимум один approver по RACI (аналитик, architect).
  • Версия документации привязана к релизу: tag или артефакт docs собирается вместе с кодом.

3.6 DevSecOps и manual approval gate

Security gates (SAST, dependency scan, проверка секретов) — критерий готовности релиза в требованиях. Механика инструментов — в 08.07 Основы кибербезопасности для системного аналитика.

При Delivery опишите manual approval gate как требование: роль утверждающего, артефакт sign-off (тикет, release checklist), максимальное время ожидания (SLA) и эскалация при просрочке. Без этого gate «зависает» незаметно для stakeholders.

3.7 Definition of Ready и Definition of Done

DoR для CI/CD-команды (до старта разработки):

  • AC в Gherkin или однозначно автоматизируемом формате.
  • Черновик OpenAPI/AsyncAPI для затронутых контрактов.
  • Тестовые данные и сценарии для staging определены.
  • Фича-флаг (если нужен) и оба состояния описаны.
  • НФТ деплоя, observability и perf-gate согласованы.

DoD — с привязкой к среде (см. раздел 2.4): CI зелёный, staging-deploy успешен, миграции и E2E пройдены; для Delivery — sign-off по RACI; для Deployment — prod smoke и метрики в норме.

DoR/DoD в Scrum-командах сопоставляйте со спринтовым циклом — 05.02 Scrum и Kanban (аналитик в Agile). Полный чеклист перед стартом — 10.04 Чеклист аналитика перед стартом разработки.

3.8 Декомпозиция и приоритизация

В CD каждый инкремент несёт измеримую ценность (→ 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)); истории дробятся по 04.02 Пользовательские истории (User Stories) и Job Stories; приоритет — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

3.9 Пример: User Story с требованиями для CI/CD

Заголовок: Как владелец продукта, я хочу, чтобы скидка 10 % для новых пользователей включалась постепенно, чтобы проверить влияние на конверсию без риска для всех посетителей.

Критерии приёмки:

  1. Фича-флаг new-user-discount управляется через админ-панель без перевыкатки сервиса.
  2. Флаг принимает значения off (скидка не применяется, UX и API идентичны текущему поведению), 10% и canary (10 % для 5 % новых пользователей).
  3. При off E2E подтверждают отсутствие скидки; при 10% и canary — соответствующее поведение.
  4. Изменение значения флага применяется не дольше 30 с после сохранения.
  5. При canary процент охвата задаётся отдельным параметром.
  6. Все изменения флага журналируются: старое значение, новое, инициатор, временная метка.
  7. После полного включения флаг удаляется в течение одного спринта.

Definition of Done:

  • CI зелёный на целевой ветке; деплой на staging успешен; E2E для off, 10% и canary пройдены.
  • При Delivery — sign-off PO в release-тикете; при Deployment — canary 5 % → 100 % по метрике конверсии.

НФТ (canary / rollback):

  • При падении конверсии новых пользователей > 2 п.п. относительно 7-дневного baseline в течение 1 ч после расширения canary — автоматический откат флага в off и алерт PO.
  • Rollback флага без redeploy: время переключения ≤ 30 с; post-deploy smoke подтверждает возврат к прежнему UX.

4. Типовые ошибки и ограничения

  • AC «на глаз»: формулировки без Given-When-Then не попадают в acceptance-стадию пайплайна.
  • Flaky E2E в blocking gate: недетерминированные AC блокируют релиз; сценарий либо стабилизируют, либо выводят из gate.
  • DoD без указания среды: «конвейер прошёл» при Delivery ≠ prod; команда спорит на релизе.
  • Staging ≠ prod: приёмка на урезанном стенде не ловит prod-дефекты.
  • Prod-PII на staging: маскирование забыли — compliance-риск при prod-like объёме данных.
  • Миграция без expand-contract: zero-downtime заявлен, но схема ломает работающую версию приложения.
  • Флаг только «on»: забыли off-state и тесты обоих режимов — canary ломает UX при откате.
  • Observability «на потом»: без метрик rollback и ручной sign-off слепы.
  • Perf gate не согласован: latency деградирует, а blocking gate отсутствует — дефект уходит в prod.
  • Quality gates не согласованы: блокировка релиза воспринимается как сюрприз, а не как выполненное требование.
  • Manual approval без SLA: gate перед prod зависает без эскалации.
  • Размытие ролей: аналитик пишет unit-тесты или QA формулирует NFR деплоя — границы из раздела 2.1 нарушены.
  • PII в CI: реальные данные клиентов в фикстурах — риск compliance (→ 08.06 Юридические и регуляторные требования РФ (PCI-DSS)).

Проверяемые и однозначные требования — базовый принцип 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148); жизненный цикл требования в CD — 02.05.05 Жизненный цикл требования.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • Джез Хамбл, Дейв Фарли. «Непрерывное развёртывание ПО» (Continuous Delivery) — фундамент конвейеров и deployable units.
  • Николь Форсгрен, Джез Хамбл, Джин Ким. «Ускоряйся: наука DevOps» (Accelerate) — DORA-метрики и связь частых деплоев с качеством.
  • ISO/IEC/IEEE 29148 — требования к verifiable requirements; см. также 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

Статьи и практические руководства

Спецификации и форматы

Курсы