Shipping and Launch

--- name: shipping-and-launch description: Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy. --- # Shipping and Launch ## Overview Ship with confidence. The goal is not just to deploy : it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental. ## When to Use - Deploying a feature to production for the first time - Releasing a significant change to users - Migrating data or infrastructure - Opening a beta or early access program - Any deployment that carries risk (all of them) ## The Pre-Launch Checklist ### Code Quality - [ ] All tests pass (unit, integration, e2e) - [ ] Build succeeds with no warnings - [ ] Lint and type checking pass - [ ] Code reviewed and approved - [ ] No TODO comments that should be resolved before launch - [ ] No console.log debugging statements in production code - [ ] Error handling covers expected failure modes ### Security - [ ] No secrets in code or version control - [ ] npm audit shows no critical or high vulnerabilities - [ ] Input validation on all user-facing endpoints - [ ] Authentication and authorization checks in place - [ ] Security headers configured (CSP, HSTS, etc.) - [ ] Rate limiting on authentication endpoints - [ ] CORS configured to specific origins (not wildcard) ### Performance - [ ] Core Web Vitals within "Good" thresholds - [ ] No N+1 queries in critical paths - [ ] Images optimized (compression, responsive sizes, lazy loading) - [ ] Bundle size within budget - [ ] Database queries have appropriate indexes - [ ] Caching configured for static assets and repeated queries ### Accessibility - [ ] Keyboard navigation works for all interactive elements - [ ] Screen reader can convey page content and structure - [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text) - [ ] Focus management correct for modals and dynamic content - [ ] Error messages are descriptive and associated with form fields - [ ] No accessibility warnings in axe-core or Lighthouse ### Infrastructure - [ ] Environment variables set in production - [ ] Database migrations applied (or ready to apply) - [ ] DNS and SSL configured - [ ] CDN configured for static assets - [ ] Logging and error reporting configured - [ ] Health check endpoint exists and responds ### Documentation - [ ] README updated with any new setup requirements - [ ] API documentation current - [ ] ADRs written for any architectural decisions - [ ] Changelog updated - [ ] User-facing documentation updated (if applicable) ## Feature Flag Strategy Ship behind feature flags to decouple deployment from release: ``typescript // Feature flag check const flags = await getFeatureFlags(userId); if (flags.taskSharing) { // New feature: task sharing return <TaskSharingPanel task={task} />; } // Default: existing behavior return null; ` **Feature flag lifecycle:** ` 1. DEPLOY with flag OFF → Code is in production but inactive 2. ENABLE for team/beta → Internal testing in production environment 3. GRADUAL ROLLOUT → 5% → 25% → 50% → 100% of users 4. MONITOR at each stage → Watch error rates, performance, user feedback 5. CLEAN UP → Remove flag and dead code path after full rollout ` **Rules:** - Every feature flag has an owner and an expiration date - Clean up flags within 2 weeks of full rollout - Don't nest feature flags (creates exponential combinations) - Test both flag states (on and off) in CI ## Staged Rollout ### The Rollout Sequence ` 1. DEPLOY to staging └── Full test suite in staging environment └── Manual smoke test of critical flows 2. DEPLOY to production (feature flag OFF) └── Verify deployment succeeded (health check) └── Check error monitoring (no new errors) 3. ENABLE for team (flag ON for internal users) └── Team uses the feature in production └── 24-hour monitoring window 4. CANARY rollout (flag ON for 5% of users) └── Monitor error rates, latency, user behavior └── Compare metrics: canary vs. baseline └── 24-48 hour monitoring window └── Advance only if all thresholds pass (see table below) 5. GRADUAL increase (25% -> 50% -> 100%) └── Same monitoring at each step └── Ability to roll back to previous percentage at any point 6. FULL rollout (flag ON for all users) └── Monitor for 1 week └── Clean up feature flag `` ### Rollout Decision Thresholds Use these thresholds to decide whether to advance, hold, or roll back at each stage: | Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) | |--------|-----------------|-------------------------------|-----------------| | Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline | | P95 latency | Within 20% of baseline | 20