deploy_safety v1.0.0

name: deploy_safety description: Ship production deploys without the outage. Pick the right rollout strategy (canary, blue-green, rolling), wire automated rollback that fires without a human, and run deploy freezes as targeted policy instead of blanket bans. Use when planning a production deploy, choosing how to release a risky change, setting up progressive delivery, or writing a freeze policy.

Deploy Safety

Purpose

Make production deploys boring: small blast radius, fast automated rollback, and a release cadence that does not depend on the calendar. This skill covers the strategy decision (how traffic meets the new version), the automation that reverses a bad release, and the policy layer (deploy freezes) that governs when changes go out.

Workflow

1. Separate deploy from release. Decide what moves code to servers vs what exposes users to new behavior. If you can expose users separately from the code push, use a feature flag and pick your code deployment strategy on operational grounds only. See the feature_flags skill for flag design.
2. Pick the strategy. Use the decision matrix in references/canary-blue-green-guide.md: canary when you need real-traffic validation of a risky change; blue-green when you need guaranteed seconds-fast rollback and can afford 2x infra during cutover; rolling for low-risk stateless updates. Record the choice and why.
3. Set the rollback plan before the deploy. Define: what metric decides the release is bad, who or what pulls the lever, and how long reversal takes. Prefer automatic levers: flag kill switch first, canary auto-abort second, blue-green traffic flip third, manual abort last. An untested rollback plan is a wish, not a plan.
4. Automate the canary gate. Wire an analysis step that runs every minute during the canary: error rate and latency compared against the stable version or a fixed threshold. Abort and revert traffic automatically on breach. Details and a working Argo Rollouts example in references/canary-blue-green-guide.md.
5. Prove the gate works. In a test cluster, deploy an image that fails the metric and assert the system aborts on its own. If rollback only ever happens because a human runs a command, the gate is not real.
6. Handle freezes as policy, not fear. A deploy freeze is for times when support is thin (holidays, peak sales, launch day), not a cure for fragile releases. Use the template in references/freeze-policy-template.md: scope it to critical paths, define the exception path, staff the on-call. Blanket freezes defer risk and create a pile-up rush when they lift.
7. Post-deploy verification. After promotion, run smoke checks (health endpoints, one real transaction path, error rate vs baseline) before declaring the release done. If anything looks off, the fastest lever is the flag flip or traffic revert, not a fresh deploy.

Output Contract

• A strategy decision with the reasoning: strategy name, blast radius if it goes bad, rollback mechanism, expected reversal time.
• An automated rollback config (or a pointer to where it lives) with the metric, threshold, evaluation interval, and failure limit.
• A freeze policy document when freezes apply: window, scope, exceptions, approver, on-call staffing.
• A test record showing the rollback gate fired automatically in a non-prod environment.

Operating Rules

1. Every deploy gets a rollback plan written down before it ships. "Roll back the deploy" is not a plan; name the lever, the metric, and the human.
2. Never promote a canary on vibes. Promotion needs passing metric gates at each step, not someone watching a dashboard and feeling good.
3. Scope failure queries to the new version only. Mixed stable-plus-canary metrics hide a failing canary behind healthy baseline traffic.
4. Rollback beats hotfix when users are already affected. Fix forward only if the blast radius is contained and the fix is already tested.
5. Freezes always include an explicit exception path (security patches, revenue-impacting bugs). A freeze nobody can break for an emergency gets broken for everything.
6. If quality and cadence conflict, the freeze lifts for fixes, never for features. Keep the rule simple enough to survive a 2 AM judgment call.