deployment-strategy
Deployment Strategy
Decide how the release reaches production, how it is verified, and how it is reversed if reality disagrees with the plan.
Context
CI/CD automates the path to deployment; deployment strategy decides how much risk to take on each step of that path. It selects the rollout pattern that matches the change's blast radius, reversibility, and operational visibility.
Use this skill when "deploy" is no longer a binary action. The questions are: canary or blue-green, full rollout or staged activation, what to verify before expanding traffic, and what exact action restores service if the release misbehaves.
Inputs
- ci-cd-pipeline -- The automated delivery path and available gates.
- build-artifacts -- The exact release package that will be deployed.
- release-plan -- The intended scope, release window, and stakeholder expectations when one exists.
Process
Step 1: Classify Release Risk
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6