CI/CD: проверки, артефакты и выпуск релиза

Оглавление · Инструменты · Деплой проекта · Лаборатория релиза

Задача: читать pipeline как граф действий с конкретными входами, результатами и полномочиями. Нужны контейнеры и готовность.

CI и два значения CD

Continuous Integration регулярно проверяет объединяемые изменения: установка зависимостей, типы, lint, тесты и сборка. Continuous Delivery готовит проверяемый релиз к выпуску; Continuous Deployment автоматически применяет его к среде после заданных условий. Слово CD само по себе не говорит, есть ли ручное согласование. Условия конкретного workflow важнее названия процесса.

flowchart LR
  Source["Ref и конкретный commit"] --> Check["Проверки на заданных входах"]
  Check --> Build["Сборка артефакта"]
  Build --> Publish["Публикация в registry"]
  Publish --> Deploy["Применение к среде"]
  Deploy --> Observe["Проверка результата и сценария"]

Отчёт тестов, собранный HTML, Docker image и работающий сервис — разные результаты. Опубликованный image может ещё не использоваться ни одним контейнером. Ошибка деплоя не отменяет публикацию image автоматически.

Workflow, task, cube и зависимости

В SourceCraft workflow состоит из tasks; task выполняет cubes на worker. needs задаёт зависимости. Разные tasks не должны рассчитывать на общие локальные файлы: результаты передаются явно через artifacts или registry. Порядок записи YAML не заменяет зависимости.

В .sourcecraft/ci.yaml действуют такие пути:

flowchart TD
  PR["PR в main / release"] --> Checks["check-task без IAM"]
  Checks --> Preview["preview-task: образы и capsule PR"]
  Main["push main"] --> Test["release-images: проверки и четыре образа test"]
  Main --> Control["control-plane: ветки, PR, native Releases"]
  Branch["push release/X.Y"] --> BranchCheck["check-task"]
  BranchCheck --> Stage["release-branch: четыре образа staging"]
  Preview --> Registry["YC Registry"]
  Test --> Registry
  Stage --> Registry
  Control --> Registry
  Registry --> Receiver["VPS сам получает данные по HTTPS"]
  Receiver --> Stable["stable + matching staging receipt"]
  Stable --> Prod["guard, backup, blue-green production"]

Проверки устанавливают workspace через frozen lockfile, Strapi отдельно через npm ci. check-static-site.mjs использует изменяемую HTTP-фикстуру и проверяет prerender, кеш, webhook, новые slug, unpublish и отказ CMS. Это серверная проверка с вымышленными данными; она не заменяет работу редактора в настоящей Strapi. Application builders используют изолированную CMS-фикстуру, а VPS наполняет полные test/PR/staging копией опубликованного production-контента.

Ref, commit и запуск

Ref — имя ветки или тега; commit — конкретное состояние исходников. Вчерашний main может отличаться от сегодняшнего. Capsule связывает точный commit, run и четыре digest. Receiver сравнивает её со свежим control snapshot, поэтому более поздний run старой ветки не должен заменить нынешнюю сборку.

PR publication берёт конфигурацию доверенного main и отдельно проверяет текущие source/target repository и SHA. Проверки feature-конфигурации разрешены только workflow checks, без IAM. Native stable Release должен совпасть с текущей release-веткой и готовым staging receipt; draft и prerelease не дают production authority.

Состав артефакта шире исходников

Обозначим сборку B(C,L,T,X) → A: C — исходники, L — lockfile, T — инструменты и базовые образы, X — внешние данные и настройки, A — артефакт. Даже при одном C изменение X может изменить A. В нашем web X включает контент CMS на момент сборки; runtime затем может обновить страницы через ISR.

Commit SHA и digest image отвечают на разные вопросы. SHA связывает исходники, digest идентифицирует полученный объект registry. SHA-tag остаётся тегом: rerun может обновить его. release.env передаёт image references с digest, чтобы VPS получил выбранный результат сборки. Это не подпись автора и не доказательство, что содержимое безопасно. Образы и digest.

Reproducible build означает повторение одинакового результата при явно фиксированных входах. Один lockfile не фиксирует CMS, плавающий patch базового image или все эффекты сборки. Текущие инфраструктурные теги не дают побитовой воспроизводимости по датам.

Build cache экономит работу; он не является свидетельством новой проверки входов. Содержимое BuildKit secret не инвалидирует cache само по себе. В Dockerfile web CMS_BUILD_ID участвует в RUN; builder передаёт точный Git SHA, поэтому новый commit меняет этот вход. Rerun того же SHA не доказывает повторное чтение изменившейся CMS: cache может использовать прежний слой. Инвалидация build cache.

BuildKit secret mount нужен для передачи token на время RUN. ARG/ENV не подходят для хранения секретов образа. Mount не мешает самой команде напечатать или скопировать секрет — корректность команды тоже проверяют. Build secrets Docker.

Полномочия этапа

PAT не передаётся CI контейнерам и VPS. BuildKit secret mount не мешает самой команде напечатать или скопировать secret, поэтому команды тоже проверяются. Название окружения не доказывает включённую защиту ветки; правила работы агентов фиксируются в AGENTS.md и документации.

Конкурентность и частичный успех

Сборки могут выполняться одновременно, но операции со стендами и production сериализуются через /opt/gheilt/deploy.lock. Lock не откатывает уже сделанное. Production transaction отдельно сохраняет intent и active receipt; после сбоя receiver восстанавливает незавершённую фазу. Совместимость CMS и восстановление backup проверяются до подключения нового цвета к общей базе.

Таймаут, отмена run и разрыв SSH могут оставить частичный результат. Не считать «job красный» доказательством, что VPS не изменился. Сначала проверяют выбранные образы, component current-ссылки и health, затем продолжают по конкретному состоянию. Совместимость миграций ограничивает возможность отката.

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