com um clique
release-checklist
Full release checklist for multi-cloud deployment (GCP + AWS)
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Full release checklist for multi-cloud deployment (GCP + AWS)
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Recurring 23-domain enterprise/ISO repository audit — governance, traceability, security, supply chain, reproducibility, observability, architecture, technical debt, DX — produces a findings report with file:line evidence and risk ratings, and preserves the audit bar via anti-patterns Q-01…Q-08
Recurring 23-domain enterprise/ISO repository audit — governance, traceability, security, supply chain, reproducibility, observability, architecture, technical debt, DX — produces a findings report with file:line evidence and risk ratings, and preserves the audit bar via anti-patterns Q-01…Q-08 (Mode: AUTO — AGENTS.md Agent Behavior Protocol applies.)
Review cloud costs against budget and identify optimization opportunities
Debug ML inference issues — latency spikes, wrong predictions, event loop blocking
Scan a service for edge-protection coverage (WAF, DDoS mitigation, rate limiting) against ADR-042/D-38 — produces a PASS/FAIL report with file:line evidence
Scan a service for edge-protection coverage (WAF, DDoS mitigation, rate limiting) against ADR-042/D-38 — produces a PASS/FAIL report with file:line evidence (Mode: AUTO — AGENTS.md Agent Behavior Protocol applies.)
| 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"}]} |
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
# Update version
export VERSION=v{MAJOR}.{MINOR}.{PATCH}
# Tag and push
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} # confirm title/body/latest look right
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").
# For each service
for SERVICE in service-a service-b service-c; do
# GCP Artifact Registry
docker build -t ${GCP_REGISTRY}/${SERVICE}:${VERSION} ${SERVICE}/
docker push ${GCP_REGISTRY}/${SERVICE}:${VERSION}
# AWS ECR
docker build -t ${AWS_REGISTRY}/${SERVICE}:${VERSION} ${SERVICE}/
docker push ${AWS_REGISTRY}/${SERVICE}:${VERSION}
done
# Update overlays (production environment for release)
# k8s/overlays/gcp-prod/kustomization.yaml → newTag: ${VERSION} (CI replaces with @sha256 digest)
kubectl apply -k k8s/overlays/gcp-prod/
kubectl rollout status deployment --all -n {namespace} --timeout=300s
# Update overlays (production environment for release)
# k8s/overlays/aws-prod/kustomization.yaml → newTag: ${VERSION} (CI replaces with @sha256 digest)
kubectl apply -k k8s/overlays/aws-prod/
kubectl rollout status deployment --all -n {namespace} --timeout=300s
/health returning 200 on all services/predict returning valid predictions/metrics being scraped by PrometheusSmoke 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.
# Manual invocation (one service, one cloud) for debugging:
kubectl --context=$CLUSTER -n $NAMESPACE port-forward svc/$SERVICE 8000:8000 &
curl -fsS http://localhost:8000/health # liveness
curl -fsS http://localhost:8000/ready # readiness (gates traffic)
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).
If any issue detected within 30 minutes:
# Rollback all services
kubectl rollout undo deployment --all -n {namespace}
kubectl rollout status deployment --all -n {namespace}
The release is complete when ALL of the following hold across BOTH clouds:
/health 200, /ready 200, /predict
returns valid response, /metrics scraped by Prometheus)releases/v<version>.md publishedops/audit.jsonl with operation
= release_deploy, result = success for each cloud × env pairIf any of these signals appears, the release is NOT complete and must
be either rolled back via /rollback (STOP) or paused for human review:
agentic/workflows/release.mdrollback (consequence path on any failure mode)security-audit (gate before build)