| name | release-checklist |
| description | Full release checklist for multi-cloud deployment (GCP + AWS) |
| allowed-tools | ["Read","Grep","Glob","Bash(git:*)","Bash(docker:*)","Bash(kubectl:*)","Bash(gh:*)","Bash(curl:*)"] |
| when_to_use | Use when preparing a version release to production across GCP and AWS. Examples: 'release v1.2.0', 'prepare production release', 'deploy new version', 'multi-cloud release'
|
| argument-hint | <version-tag> [service-name] |
| arguments | ["version-tag"] |
| authorization_mode | {"pre_flight_checks":"AUTO","build_images":"AUTO","deploy_dev":"AUTO","deploy_staging":"CONSULT","deploy_production":"STOP","rollback_invocation":"STOP","escalation_triggers":[{"quality_gate_fail":"STOP"},{"sbom_missing":"STOP"},{"kyverno_policy_fail":"STOP"},{"disagreement_in_metrics":"CONSULT"}]} |
Release Checklist
Pre-Release Verification
Code Quality
Model Quality
Infrastructure
Documentation
Version Tagging
Before tagging, confirm the coherence gate is green — it checks (among
other things, C6) that releases/v{VERSION}.md exists, which is what the
GitHub Release will be built from:
python3 scripts/check_doc_coherence.py
export VERSION=v{MAJOR}.{MINOR}.{PATCH}
git tag -a ${VERSION} -m "Release ${VERSION}: {summary}"
git push origin ${VERSION}
Do not run gh release create / gh release edit after this. Pushing
the tag triggers .github/workflows/release-on-tag.yml (AUTO), which
publishes the GitHub Release automatically — title from
releases/${VERSION}.md's H1, full file as the body, --latest computed
for the active v0.x line. Verify it published correctly instead:
gh release view ${VERSION}
If the published Release has the wrong title/body, the fix is in
release-on-tag.yml or releases/${VERSION}.md — not a manual
gh release edit patching the symptom (rule 16 §"Release publication is
automatic").
Build and Push Images
for SERVICE in service-a service-b service-c; do
docker build -t ${GCP_REGISTRY}/${SERVICE}:${VERSION} ${SERVICE}/
docker push ${GCP_REGISTRY}/${SERVICE}:${VERSION}
docker build -t ${AWS_REGISTRY}/${SERVICE}:${VERSION} ${SERVICE}/
docker push ${AWS_REGISTRY}/${SERVICE}:${VERSION}
done
Deploy to GCP
kubectl apply -k k8s/overlays/gcp-prod/
kubectl rollout status deployment --all -n {namespace} --timeout=300s
Deploy to AWS
kubectl apply -k k8s/overlays/aws-prod/
kubectl rollout status deployment --all -n {namespace} --timeout=300s
Post-Deploy Verification
Both Clouds
Smoke Tests
Smoke tests run inside the deploy chain via deploy-common.yml
(canonical SSOT). Each environment job invokes the smoke test step
against the freshly-deployed pods; failure halts the chain.
kubectl --context=$CLUSTER -n $NAMESPACE port-forward svc/$SERVICE 8000:8000 &
curl -fsS http://localhost:8000/health
curl -fsS http://localhost:8000/ready
curl -fsS -X POST http://localhost:8000/predict \
-H 'content-type: application/json' \
-d "$(cat tests/fixtures/smoke_payload.json)"
kill %1
For a multi-service / multi-cloud sweep, drive the loop from a
runbook page or a CI workflow-dispatch — the template does not ship
a scripts/smoke_test.py script (would compete with deploy-common.yml
as SSOT).
Rollback Plan
If any issue detected within 30 minutes:
kubectl rollout undo deployment --all -n {namespace}
kubectl rollout status deployment --all -n {namespace}
Post-Release
Success criteria
The release is complete when ALL of the following hold across BOTH clouds:
Failure modes — must STOP before completion
If any of these signals appears, the release is NOT complete and must
be either rolled back via /rollback (STOP) or paused for human review:
- Quality gate fail at any stage
- Cosign verification fail at admission (Kyverno blocks the pod)
- SBOM attestation older than 90 days (rule 14 §retention)
- Smoke test 5xx rate > 0.5% in any environment for > 60s
- Slice metric regression > 5pp on any monitored slice (ADR-007)
Related
- Workflow:
agentic/workflows/release.md
- Skill:
rollback (consequence path on any failure mode)
- Skill:
security-audit (gate before build)
- ADR-011 — Environment promotion gates