Deployment Strategist

Deployment Strategist

When to Use

• Choose a rollout pattern such as canary, blue-green, rolling, shadow, or feature-flagged release
• Write production rollout, cutover, rollback, or recovery plans
• Coordinate deploy strategy for schema changes, migrations, multi-region releases, or high-risk launches
• Define entry/exit criteria, health metrics, and go/no-go checks for phased deployment
• Brief stakeholders on release risk, blast radius, and contingency plans

When NOT to Use

• Implement CI/CD YAML, GitOps sync, or build systems → devops
• Provision VPCs, clusters, networking, or Terraform modules → infrastructure-engineer
• Add pipeline security gates or supply-chain controls → devsecops
• Manage multi-team program milestones and RAID logs → technical-program-manager
• Write cross-service architecture ADRs before implementation → senior-system-architecture

Related skills

Core Workflows

1. Strategy selection

Decision inputs:

Default recommendations:

See `references/strategy_selection.md` for decision tree and trade-off matrix.

2. Rollout plan document

Produce a plan containing:

1. Objective — what changes, for whom, by when 2. Scope — services, regions, tenants, feature flags 3. Phases — dev → staging → prod canary → prod 100% 4. Entry/exit criteria per phase (metrics, tests, approvals) 5. Rollback — trigger conditions, owner, steps, data implications 6. Comms — internal channels, customer status page if needed 7. Schedule — timezone-aware; avoid peak and freeze windows

See `references/rollout_planning.md` for template and stakeholder RACI.

3. Environment and promotion design

• Minimum: dev, staging, prod (prod-like staging mandatory for risky changes)
• Optional: preview per PR, perf, disaster-recovery drill env
• Promotion = new artifact digest, not rebuild; same artifact across stages
• Config via environment overlays; secrets from vault

See `references/environments_promotion.md` for topology patterns and config rules.

4. Database and dependency coordination

Expand-contract pattern for schema:

1. Expand: deploy code tolerant of old and new schema 2. Migrate data 3. Contract: remove old paths in later deploy

Never drop columns or rename in same release as code depends on new shape without dual-write.

See `references/strategy_selection.md` for coupled release patterns.

5. Rollback and recovery

Define rollback triggers before deploy: error rate, SLO burn, failed smoke, manual abort.

See `references/rollback_recovery.md` for playbooks and drill cadence.

6. Risk, compliance, and sign-off

• Map change to risk tier (low / medium / high)
• High: CAB or change ticket, maintenance window, extra approvers
• Document blast radius and tested rollback
• Post-deploy verification window with named owner

See `references/risk_compliance.md` for tier definitions and evidence list.

When to load references

• Choose strategy → references/strategy_selection.md
• Rollout plan template → references/rollout_planning.md
• Environments → references/environments_promotion.md
• Rollback → references/rollback_recovery.md
• Change control → references/risk_compliance.md

Environments and promotion

Table of contents

1. Topology patterns 2. Promotion rules 3. Config and secrets

Topology patterns

Promotion rules

• Promote artifact digest built once in CI
• Staging must run same digest intended for prod
• No hot patches on prod without backport to git
• Tag release in git matching deployed digest

Config and secrets

Parity: staging uses same secret shape as prod; different values.

Risk and compliance

Table of contents

1. Change tiers 2. Change windows 3. Evidence checklist

Change tiers

Change windows

• Blackout: peak traffic, holidays, fiscal close
• Preferred: low-traffic window with on-call staffed
• Multi-region: roll forward by region (low-risk region first)

Evidence checklist

Attach to change ticket:

• [ ] Rollout plan link
• [ ] Rollback tested date
• [ ] Eval/test results
• [ ] Dashboard links for canary
• [ ] Comms sent (if external)
• [ ] Post-deploy verification sign-off

Rollback and recovery

Table of contents

1. Rollback triggers 2. Playbooks 3. Drills

Rollback triggers

Define before deploy:

Playbooks

Application rollback (preferred):

1. Stop traffic to bad version (canary weight 0 or blue-green switch) 2. Deploy previous known-good digest from registry 3. Run smoke tests 4. Confirm metrics normalized within 15 min

Feature-flag rollback:

1. Disable flag globally 2. Keep deploy in place if code path is inert when flag off

Database rollback:

• Avoid if possible; use forward fix
• Restore from backup only with explicit approval and RPO acceptance

Drills

Quarterly: rollback prod-like staging to previous digest in < RTO target.

Document actual elapsed time and gaps.

Rollout planning

Table of contents

1. Plan template 2. Phase criteria 3. RACI

Plan template

# Rollout: [Release name]
**Date / window:**  
**Owner:**  
**Risk tier:** Low | Medium | High

## Summary
[What ships and why]

## Scope
- Services:
- Regions:
- Feature flags:

## Phases
| Phase | % traffic | Entry criteria | Exit criteria | Owner |
|-------|-----------|----------------|---------------|-------|

## Rollback
**Triggers:**  
**Steps:**  
**Data impact:**

## Comms
- Internal:
- External:

## Verification
- [ ] Smoke tests
- [ ] Dashboards
- [ ] On-call briefed

Phase criteria

Example canary exit (all required):

• Error rate ≤ baseline + 0.1%
• p95 latency ≤ baseline + 10%
• No SEV1/2 alerts
• 30 minutes stable at current weight

RACI

Strategy selection

Table of contents

1. Decision tree 2. Trade-off matrix 3. Coupled releases

Decision tree

Need instant traffic rollback at LB?
  yes → blue-green or canary with traffic manager
  no  → rolling may suffice

Schema or data migration required?
  yes → expand-contract + phased deploy; avoid big-bang

Canary metrics trustworthy within 5–15 min?
  yes → canary (5% → 25% → 100%)
  no  → blue-green with manual validation window

User-facing behavior risky?
  yes → feature flags decouple deploy from release

Trade-off matrix

Coupled releases