# Deployment Strategy

> Deploy with rollback plans, staged rollouts, and feature flags

- Skill: `vignesh2027/deployment-strategy` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vignesh2027/deployment-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vignesh2027/deployment-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: vignesh2027 (https://skillmd.com/u/vignesh2027)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vignesh2027/deployment-strategy

---


## Overview

Deployments fail. The question is not whether, but whether you can recover quickly. This skill makes deployments reversible, observable, and gradual.

## When to Use

- Before every production deployment
- When designing a deployment pipeline
- When a deployment caused a production incident
- As part of the `/ship` workflow

## Process

### Step 1: Write the rollback procedure first
Before deploying, document how to roll back. If you can't write the rollback procedure, you're not ready to deploy.

### Step 2: Define the rollout stages
1% → 10% → 50% → 100% for high-risk changes.
10% → 100% for low-risk changes.
Never: 0% → 100% for anything that touches user-visible behavior.

### Step 3: Choose a deployment strategy
- **Blue/green**: spin up new environment, switch traffic, keep old environment warm for rollback
- **Canary**: route a percentage of traffic to new version, measure, expand
- **Feature flags**: deploy code dark, flip flag to enable for users
- **Rolling**: replace instances one by one, abort if errors spike

Choose based on: how reversible is the change? How quickly can you detect problems?

### Step 4: Define the deployment success criteria
Before deploying: what metrics must hold for the deployment to be considered successful?
- Error rate stays below X%
- p99 latency stays below Y ms
- No new error types in logs
- Key business metric (signups, orders) not regressing

### Step 5: Bake time
After deploying to a stage: wait before expanding. Minimum bake time:
- 1% stage: 15 minutes
- 10% stage: 1 hour
- 50% stage: 4 hours

High-risk changes need longer bake times.

### Step 6: Database migrations
- Migrations must be backward compatible (old code + new schema must work)
- Deploy migration before new code; keep old code running
- Never delete a column in the same release that stops using it
- Test rollback of the migration

### Step 7: Automate the deployment gate
Success criteria from Step 4 must be checked automatically. If they fail, the deployment halts. Not: "someone watches the dashboard." Automatic.

### Step 8: Post-deployment monitoring
After a deployment: watch the golden signals for 24 hours. Document any anomalies.

## Anti-Rationalizations

**"It's a small change — we can deploy to 100%"**
"Small" changes cause production incidents. All production changes go through staged rollout.

**"We can roll back if there's a problem"**
"Can roll back" means the rollback procedure is written, tested, and can be executed in under 5 minutes. Otherwise, you don't have a rollback plan; you have a hope.

## Verification Requirements

- [ ] Rollback procedure written before deployment starts
- [ ] Deployment stages defined (not 0% → 100%)
- [ ] Success criteria defined and automated
- [ ] Bake time defined at each stage
- [ ] Database migrations are backward compatible
- [ ] Post-deployment monitoring planned