forgivesam168 Shipping and Launch
Safe, controlled production deployments with rollback readiness.
Scope vs work-archiving
| This Skill | work-archiving |
|---|---|
| External deployment to production | Internal change package finalization |
| Rollout strategy, monitoring, go/no-go | 99-archive.md, CHANGELOG, ADR |
| Customer-facing launch coordination | Team-facing knowledge archiving |
Use work-archiving to close out the change package internally, then use this skill to manage the actual production deployment.
When to Use
- Feature is code-review approved and ready for production
- Planning a staged or phased rollout (canary, blue-green, feature flag)
- Need a rollback plan before deploying
- Running a production readiness checklist
- Deciding go / no-go for a launch
Process
Step 1: Pre-Launch Readiness Check
Before any deployment:
- All tests passing (CI green on the target branch)
- Security review completed (Quick Gate ≥ 8/10)
- Feature flags configured (if using staged rollout)
- Rollback plan documented (see Step 2)
- Monitoring / alerting in place for this feature
- On-call engineer identified and available
Step 2: Rollback Plan（必須先寫，才能部署）
Document the rollback plan before deployment begins:
## Rollback Plan: [Feature Name]
**Rollback Trigger**: [Condition that triggers rollback — e.g., "error rate > 1% for 5 min"]
**Rollback Method**: [How to revert — feature flag off / git revert / DB migration down]
**Rollback Owner**: [Who executes — on-call engineer]
**Rollback Time Estimate**: [How long to revert — e.g., "< 5 minutes"]
**Data Impact**: [Any data written during deployment that needs cleanup?]
Step 3: Staged Rollout Strategy
Choose a rollout strategy based on risk level:
| Strategy | Risk Level | Description |
|---|---|---|
| Full Deploy | Low | All users at once; simple features with low blast radius |
| Feature Flag | Medium | Enable for % of users or specific segments; toggle off on incident |
| Canary | Medium-High | Deploy to small % of traffic first; monitor before expanding |
| Blue-Green | High | Run two environments; switch traffic atomically; easy rollback |
Step 4: Go / No-Go Decision
Before flipping traffic:
| Check | Owner | Status |
|---|---|---|
| CI passing on deploy branch | Eng | ☐ |
| Rollback plan documented | Eng | ☐ |
| Monitoring dashboards ready | Ops | ☐ |
| Stakeholder sign-off (if customer-facing) | PM | ☐ |
| Peak traffic window avoided | Eng | ☐ |
Any unchecked → No-Go. Do NOT deploy until all checks pass.
Step 5: Post-Launch Monitoring
Watch for the first 30 minutes after deployment:
- Error rate vs baseline (≤ 0.1% increase acceptable)
- P99 latency vs baseline (≤ 20% increase acceptable)
- Key business metrics (conversion, signups, payments — no regression)
If any threshold breached → execute rollback plan immediately.
Common Rationalizations
在準備上線過程中，AI 可能以下列藉口略過安全步驟：
| 常見藉口 | 反制說明 |
|---|---|
| "功能已測試通過，直接上線就好" | ⛔ 測試通過 ≠ 上線準備完成——測試確認行為正確，上線準備確認系統容忍失敗；rollback plan 是非談判項目 |
| "這個功能很小，不需要 staged rollout" | 影響範圍是衡量標準，不是功能大小——任何觸及支付/認證/資料遷移的「小功能」都需要至少 feature flag 保護 |
| "rollback 我知道怎麼做，不用寫下來" | 事故發生時的壓力會讓「我知道」消失——rollback plan 必須是可被任何 on-call 工程師執行的書面文件 |
| "監控之後再設，先把功能上了" | 無監控的部署是盲飛——監控必須在 go-live 前就位，否則無法在 30 分鐘窗口內偵測回歸 |
Verification
在執行任何生產部署前，逐項確認：
-
Test-Path docs/rollback-plan.md或 rollback plan 已記錄於99-archive.md回傳 True - Go / No-Go 清單所有項目均已確認（無未檢查項目）
- 監控 / 告警已就位，並在部署前進行煙霧測試驗證
- 選擇的 rollout 策略與功能風險等級匹配（High risk → Canary 或 Blue-Green）
- 部署時間視窗已確認：非尖峰時段、on-call 工程師在線
- 若有資料遷移，已確認正向 + 反向遷移腳本均通過測試