Инженерия релиза: полевой разбор расхождений версии, artifact и migration

Представим один field-разбор без реальной среды. Карточка A связывает 2024.07.0, synthetic-commit-7f4a0c1, digest sha256:synthetic-2024-07-0-a1 и compatible migration. Карточка B держит тот же release number, но artifact ссылается на другой commit. Карточка C держит правильный artifact, зато migration уже помечена 2024.07.1. Карточка D просит в rollout card другой digest. Все четыре — fixed versioned objects из memory fixture, не delivery records. Их цена как учебного упражнения в том, что похожие названия перестают успокаивать и заставляют назвать точку расхождения.

Симптом полевого разбора: участники видят «версия одна», а спорят о том, стоит ли повторить deploy или открыть incident. Причина глубже: разные классы несовпадений ведут к одному общему действию — retry. Проверка должна идти по направлению цепочки и останавливаться на первой broken relation. Действие тогда конкретно: mismatch commit требует исправить artifact evidence, mismatch migration — проверить contract и compatibility, mismatch digest — переписать rollout intent. Никакая из этих веток не даёт fixture права вызвать CI, registry или target environment.

Четыре fixed cases как тренировочный материал

Aligned case полезен не потому, что он «зелёный». Он показывает минимальный набор facts, который можно сравнить: artifact declares source commit, migration target совпадает с release, migration объявлена compatible с return version, а rollout card повторяет exact digest и migration version. Это приводит лишь к continue-to-human-deploy-review. Слово human важно: fixture не даёт approval и не запускает операцию, даже когда все собственные predicates true. Она отделяет согласованность description от факта исполнения.

Artifact-commit mismatch говорит другую вещь. Версия и даже prefix digest могут выглядеть ожидаемо, но artifact.sourceCommitId не равен source commit. Это не повод угадать, какой из двух объектов «вернее». Правильный outcome — stop-and-reconcile-records с причиной artifact-does-not-bind-commit. Полевой reviewer получает точный вопрос: кто исправляет source relation и какое authorised evidence потом сравнит её снова? Сравнение не заменяется новым build и не маскируется повтором deploy, потому что исходное несоответствие ещё не объяснено.

Рабочая таблица разбора

Таблица нужна полевому разбору, чтобы не превратить verdict в эмоцию. У всех stop cases одинаковая дисциплина — ничего не исполнять из fixture, — но причина и владелец следующего вопроса различаются. Artifact mismatch чаще всего начинается у source relation; migration mismatch — у compatibility boundary; digest mismatch — у intent. Когда эти случаи складываются в одну категорию «release failed», потеряется информация, которую надо принести в review. А когда у каждого есть короткое название, переписать или уточнить можно до того, как начнётся дорогое действие.

Исполнимая проверка негативных веток

Функция runReleaseEvidenceFixture() возвращает полный набор fixed samples и map assertions. Она проверяет positive case, три вида расхождений, лишние CI-like и deploy-like input fields, подменённый report, подменённый rollback draft и попытку получить rollback из stop decision. Это важнее одной happy path: release discipline ломается именно там, где один объект слегка изменили, а следующий шаг всё равно продолжился. Команда ниже выполняет только Node code из данного файла; у неё нет client library, credentials, endpoint или файлового input.

import { runReleaseEvidenceFixture } from './upgrade-2024-07.mjs';

const fixture = runReleaseEvidenceFixture();
const failed = Object.entries(fixture.assertions)
  .filter(([, value]) => value !== true)
  .map(([name]) => name);

if (failed.length > 0) throw new Error(failed.join(", "));
console.log('fixed synthetic evidence checks passed');

// The four cases are versioned JS records held in memory, not delivery evidence.
node web/scripts/upgrade-2024-07.mjs --verify-fixture

Позитивная assertion здесь не является релизным подтверждением. Она доказывает лишь, что fixed record, который автор положил в source code, согласован сам с собой по написанным predicates. Отрицательная assertion также не доказывает ошибку в реальном процессе. Она доказывает, что модель не пропускает известный bad shape. Это правильный масштаб автоматического примера: тестировать не то, что он не может видеть, а границу, на которой он обязан сказать «я не знаю; остановись и проверь разрешённый источник».

Маршрут field triage

1. Зафиксируйте точку чтения. Сначала выберите один record и явно пометьте, что это input для review, а не execution command. Не смешивайте with current environment state.
2. Сравните commit и artifact. Проверяйте exact source relation и digest, не только semantic version. При mismatch запишите named reason и owner исходной записи.
3. Сравните migration и release. Target version и compatibility должны быть описаны отдельно. Если migration unknown или относится к будущей версии, маршрут заканчивается stop.
4. Сравните rollout intent с artifact и migration. Intent обязан повторить immutable digest и exact migration version. Если он иной, не исправляйте его устно.
5. Проверьте return point. До approval назовите return version/digest и ограничение: code/artifact return не равен автоматическому data undo.
6. Передайте только открытый вопрос. Aligned card передаётся authorised human reviewer; stop card — владельцу discrepancy. Ни одна ветка fixture не передаётся deployment client.

Rollback без героической легенды

Контролируемый rollback не обязан быть мгновенным, чтобы быть полезным. Он обязан быть точным. В fixture для aligned case есть return version 2024.06.3 и return digest sha256:synthetic-2024-06-3-z9. Функция draftSyntheticControlledRollback() создаёт teaching draft только после canonical plan: она снова сравнивает report с fixed record и отказывает при изменённом action. Draft называет, куда мог бы вернуться code/artifact review, но у него поля deployment: not-created-or-run и effect: no-system-change. Это принципиально не rollout.

Migration boundary остаётся наиболее важной строкой return draft. В ней прямо сказано does-not-reverse-data-and-requires-separate-human-review. Так field reviewer не теряет вопрос о данных в момент, когда все устали и хотят «просто вернуть вчерашний образ». Kubernetes documentation помогает поставить правильную границу: rollback Deployment связан с его revision Pod template. В вашей системе migration может иметь свои механизмы, lock, compatibility period или запрет на reverse. Именно поэтому field triage обязан отправить data question отдельному owner-у, а не присвоить ему успех вслед за возвратом binary.

Ограничения разбора

Ревизия не анализирует настоящие commit, container image, registry metadata, provenance signature, CI configuration, environment protection rules, database schema, cloud account, traffic, telemetry или production response. Она также не выдаёт SLSA level, не проверяет GitHub attestation и не запускает Kubernetes API. Официальные источники в конце помогают удержать terminology и историческую границу, но не являются доказательством того, что конкретная команда использует эти возможности. Ещё меньше они позволяют заключить, что любой record с digest можно безопасно deploy или rollback.

У field pattern есть сознательное ограничение масштаба: он хорошо ловит disagreement между named records, но не отвечает, почему values были записаны именно такими. Это следующий слой — authorised evidence collection, trust model, signature verification, migration rehearsal и target-specific policy. Если начать тянуть эти задачи в один fixture, он станет непрозрачной копией pipeline и всё равно не получит реального доступа. Лучше оставить маленький deterministic test рядом с формой и вести реальные процедуры в отдельном, разрешённом контуре.

Следующий проверяемый шаг

Проведите tabletop review на бумаге: один author заполняет пять полей для вымышленного release, второй получает только таблицу связей и должен найти один из трёх заранее внесённых mismatch. Никакие реальные name, URL, digest, migration или deploy targets не нужны. Успех измеряется не скоростью и не зелёным status, а тем, что reviewer называет precise broken relation, stop action, owner следующего вопроса и границу rollback. После этого можно сравнить форму с одним разрешённым рабочим процессом, но не заменять tabletop result production claim.

Историческая граница июля 2024

К июлю 2024 уже были доступны три первичных опоры, на которые ссылается текст: stable SLSA v1.0, GitHub Artifact Attestations generally available с 25 июня 2024 и versioned Kubernetes 1.30 documentation о Deployments. Они не используются для прогнозов, рекомендаций конкретного cloud или утверждений о существующей delivery system. Все case ids, commit ids, digest, migration plans, rollout cards, decisions и return drafts в этой ревизии — versioned fixed synthetic JS objects in memory. Их purpose — проверить reasoning, не имитировать pipeline.

Проверяемые источники

• GitHub Changelog: Artifact Attestations is generally available, 25 июня 2024 — Первичный датированный источник GitHub: в GitHub Actions можно создать attestation для собранного artifact и затем проверить его. Здесь это основание различать artifact и проверяемое утверждение о нём; источник не является policy, журналом или доказательством чужого выпуска.
• SLSA: SLSA v1.0 is now final!, 19 апреля 2023 — Первичная публикация о первом stable SLSA v1.0. Из неё взята узкая идея versioned provenance и проверки ожиданий, а не claim, что любой набор полей делает конкретную сборку безопасной или готовой к deploy.
• Kubernetes documentation: Deployments, snapshot 14.03.2024 — Первичный неизменяемый снимок ветки release-1.30, доступный до июля 2024: revision Deployment связана с Pod template, а rollback возвращает прежнюю revision шаблона. Это не отменяет data migration и не переносится автоматически на другой deploy-инструмент.