Shipping and Launch
Overview
Ship to production with confidence using pre-launch checklists, staged rollouts, and verified rollback procedures. Faster is safer: small, frequent releases are less risky than large, infrequent ones.
When to Use
- Preparing to deploy any change to production
- Launching a new feature or significant change
- After completing code review and quality gates
Pre-Launch Checklist
Code Quality
Security
Performance
Operational
Feature Flag Lifecycle
- Create: Add flag in default-off state
- Develop: Implement behind the flag
- Test: Enable for internal users and automated tests
- Roll Out: Enable for percentage of users
- General Availability: Enable for all users
- Cleanup: Remove flag and old code path
Staged Rollout
Stage 1: Internal
- Deploy to staging
- Enable for internal team
- Verify functionality and monitoring
Stage 2: Canary
- Enable for 1-5% of users
- Monitor error rates and performance
- Compare against baseline metrics
Stage 3: Expanded
- Enable for 25-50% of users
- Continue monitoring
- Verify no edge case regressions
Stage 4: General Availability
- Enable for all users
- Monitor for 24-48 hours
- Remove feature flag in next release
Rollback Procedure
Automatic Rollback
Triggered by:
- Error rate exceeds threshold
- Response time exceeds SLO
- Health check failures
Manual Rollback
- Identify the failing deployment
- Revert to the last known good deployment
- Verify the rollback resolved the issue
- Communicate the rollback to stakeholders
- Investigate root cause before re-deploying
Process
Step 1: Complete Pre-Launch Checklist
Work through every item. Any unchecked item is a blocker.
Step 2: Deploy to Staging
- Verify the deployment succeeds
- Run smoke tests against staging
- Check monitoring dashboards
Step 3: Execute Staged Rollout
- Follow the rollout stages above
- Monitor at each stage
- Rollback if metrics degrade
Step 4: General Availability
- Enable for all users
- Monitor for 24-48 hours
- Schedule feature flag cleanup
Common Rationalizations
| Rationalization |
Reality |
| "It works on staging, ship it" |
Staging does not perfectly replicate production traffic and data. |
| "We can monitor after launch" |
Monitoring should be configured before launch, not after. |
| "Rollback is too slow, just fix forward" |
Fixing forward under pressure introduces more risk than a clean rollback. |
Verification
Anti-Rationalization Table
| Excuse |
Counter |
| "It works on staging, ship it" |
Staging does not perfectly replicate production traffic and data. |
| "We can monitor after launch" |
Monitoring should be configured before launch, not after. |
| "Rollback is too slow, just fix forward" |
Fixing forward under pressure introduces more risk than a clean rollback. |
| "Staged rollout is too slow, just enable for everyone" |
Staged rollouts catch issues before they affect all users. They are faster than incident response. |
| "The feature flag cleanup can wait" |
Uncleaned feature flags become permanent technical debt. Schedule cleanup immediately. |
Imported from cursor-team-kit/review-and-ship (MIT, cursor/plugins)
Review and ship
Trigger
Reviewing changes before shipping. Close key issues, verify behavior, and open or update a PR.
Workflow
- Gather context: diff against base branch, uncommitted changes, recent commits, changed files, and user intent from recent relevant chats if useful.
- Run targeted tests for changed behavior. If no focused tests exist, decide whether to add them or document the gap.
- Review for correctness, regressions, security, and intent fit. Use parallel subagents for larger diffs.
- Fix critical issues before finalizing and re-run affected tests.
- Commit selective files with a concise message.
- Push branch and open or update a PR.
Suggested Checks
git fetch origin main
git diff origin/main...HEAD
git status
gh pr checks --json name,bucket,state,workflow,link
Guardrails
- Prioritize correctness, security, and regressions over style-only comments.
- Keep commits focused and avoid unrelated file changes.
- If pre-commit checks fail, fix the issues rather than bypassing hooks.
- Use
gh pr checks instead of GitHub Actions-only commands when judging PR readiness.
Output
- Findings summary (critical, warning, note)
- Tests run and outcomes
- PR URL
1---2name: shipping-and-launch-23description: Pre-launch checklists, feature flag lifecycle, staged rollouts, rollback procedures, monitoring setup. Use when preparing to deploy to production.4---56# Shipping and Launch78## Overview910Ship to production with confidence using pre-launch checklists, staged rollouts, and verified rollback procedures. Faster is safer: small, frequent releases are less risky than large, infrequent ones.1112## When to Use1314- Preparing to deploy any change to production15- Launching a new feature or significant change16- After completing code review and quality gates1718## Pre-Launch Checklist1920### Code Quality2122- [ ] All tests pass (unit, integration, e2e)23- [ ] Code review approved24- [ ] No critical or high-severity issues open25- [ ] Coverage meets 80% threshold2627### Security2829- [ ] No secrets in code or configuration30- [ ] Dependency audit shows no critical vulnerabilities31- [ ] Input validation at all trust boundaries32- [ ] Authentication and authorization tested3334### Performance3536- [ ] Performance baseline established37- [ ] No regressions in Core Web Vitals or response times38- [ ] Database queries analyzed for N+1 patterns39- [ ] Load tested if the change affects throughput4041### Operational4243- [ ] Feature flag created for new behavior44- [ ] Monitoring and alerting configured45- [ ] Rollback procedure documented and tested46- [ ] Staging deployment verified4748## Feature Flag Lifecycle49501. **Create**: Add flag in default-off state512. **Develop**: Implement behind the flag523. **Test**: Enable for internal users and automated tests534. **Roll Out**: Enable for percentage of users545. **General Availability**: Enable for all users556. **Cleanup**: Remove flag and old code path5657## Staged Rollout5859### Stage 1: Internal6061- Deploy to staging62- Enable for internal team63- Verify functionality and monitoring6465### Stage 2: Canary6667- Enable for 1-5% of users68- Monitor error rates and performance69- Compare against baseline metrics7071### Stage 3: Expanded7273- Enable for 25-50% of users74- Continue monitoring75- Verify no edge case regressions7677### Stage 4: General Availability7879- Enable for all users80- Monitor for 24-48 hours81- Remove feature flag in next release8283## Rollback Procedure8485### Automatic Rollback8687Triggered by:88- Error rate exceeds threshold89- Response time exceeds SLO90- Health check failures9192### Manual Rollback93941. Identify the failing deployment952. Revert to the last known good deployment963. Verify the rollback resolved the issue974. Communicate the rollback to stakeholders985. Investigate root cause before re-deploying99100## Process101102### Step 1: Complete Pre-Launch Checklist103104Work through every item. Any unchecked item is a blocker.105106### Step 2: Deploy to Staging107108- Verify the deployment succeeds109- Run smoke tests against staging110- Check monitoring dashboards111112### Step 3: Execute Staged Rollout113114- Follow the rollout stages above115- Monitor at each stage116- Rollback if metrics degrade117118### Step 4: General Availability119120- Enable for all users121- Monitor for 24-48 hours122- Schedule feature flag cleanup123124## Common Rationalizations125126| Rationalization | Reality |127|---|---|128| "It works on staging, ship it" | Staging does not perfectly replicate production traffic and data. |129| "We can monitor after launch" | Monitoring should be configured before launch, not after. |130| "Rollback is too slow, just fix forward" | Fixing forward under pressure introduces more risk than a clean rollback. |131132## Verification133134- [ ] Pre-launch checklist is complete135- [ ] Feature flag is configured for staged rollout136- [ ] Monitoring and alerting are in place137- [ ] Rollback procedure is tested138- [ ] Stakeholders are informed of the launch timeline139140## Anti-Rationalization Table141142| Excuse | Counter |143|--------|---------|144| "It works on staging, ship it" | Staging does not perfectly replicate production traffic and data. |145| "We can monitor after launch" | Monitoring should be configured before launch, not after. |146| "Rollback is too slow, just fix forward" | Fixing forward under pressure introduces more risk than a clean rollback. |147| "Staged rollout is too slow, just enable for everyone" | Staged rollouts catch issues before they affect all users. They are faster than incident response. |148| "The feature flag cleanup can wait" | Uncleaned feature flags become permanent technical debt. Schedule cleanup immediately. |149150## Imported from cursor-team-kit/review-and-ship (MIT, cursor/plugins)151152# Review and ship153154## Trigger155156Reviewing changes before shipping. Close key issues, verify behavior, and open or update a PR.157158## Workflow1591601. Gather context: diff against base branch, uncommitted changes, recent commits, changed files, and user intent from recent relevant chats if useful.1612. Run targeted tests for changed behavior. If no focused tests exist, decide whether to add them or document the gap.1623. Review for correctness, regressions, security, and intent fit. Use parallel subagents for larger diffs.1634. Fix critical issues before finalizing and re-run affected tests.1645. Commit selective files with a concise message.1656. Push branch and open or update a PR.166167## Suggested Checks168169```bash170git fetch origin main171git diff origin/main...HEAD172git status173gh pr checks --json name,bucket,state,workflow,link174```175176## Guardrails177178- Prioritize correctness, security, and regressions over style-only comments.179- Keep commits focused and avoid unrelated file changes.180- If pre-commit checks fail, fix the issues rather than bypassing hooks.181- Use `gh pr checks` instead of GitHub Actions-only commands when judging PR readiness.182183## Output184185- Findings summary (critical, warning, note)186- Tests run and outcomes187- PR URL
v1truv1us