--- name: software-release-management description: Manage software releases including release planning, version management, change advisory board, deployment strategies, rollback procedures, and release communication. Use when planning releases, managing version control, coordinating deployments, or handling release incidents. Triggers on phrases like "release management", "release planning", "version management", "semantic versioning", "release notes", "deployment strategy", "canary release", "blue-green deployment", "feature flags", "change advisory board", "CAB", "rollback plan", "release calendar", "release train", "hotfix", "patch release". --- # Software Release Management Manage software releases including release planning, version management, deployment strategies, rollback procedures, and release communication. ## Workflow ### 1. Release Planning ``` RELEASE CALENDAR ═══════════════════════════════════════ Release Types: ═══════════════════════════════════════ Type Frequency Duration Scope Approval ─────────────────────────────────────────────────────────────────────── Major (vX.0) Quarterly 2 weeks New features CTO + Product Minor (vX.Y) Bi-weekly 1 week Enhancements VP Engineering Patch (vX.Y.Z) As needed 1 day Bug fixes Engineering Manager Hotfix Emergency 4 hours Critical fix On-call + Eng Manager RELEASE TRAIN (Quarterly): ═══════════════════════════════════════ Q1 2025 Release Plan: ═══════════════════════════════════════ Phase Dates Activities ─────────────────────────────────────────────────────────────────────── Planning Jan 1-15 Backlog grooming, scope definition Development Jan 16-Mar 15 Sprint development (8 sprints) Hardening Mar 16-22 Bug fixing, performance testing Staging Mar 23-29 UAT, security review, load testing Release Readiness Mar 30 Final sign-off, release notes Go-Live Mar 31 Deployment (canary → full rollout) Hypercare Apr 1-7 Enhanced monitoring, rapid response ─────────────────────────────────────────────────────────────────────── RELEASE CRITERIA: ═══════════════════════════════════════ Exit criteria for each phase: → All planned features complete (or deferred with approval) → Test coverage > 80% (unit) → All P1/P2 bugs resolved → Performance benchmarks met → Security scan: 0 critical/high CVEs → Documentation updated → Rollback plan tested → Stakeholder sign-off ``` ### 2. Version Management ``` SEMANTIC VERSIONING (SemVer) ═══════════════════════════════════════ Format: MAJOR.MINOR.PATCH MAJOR: Breaking changes (incompatible API changes) → Example: v2.0.0 — API response format changed → Action: All consumers must update → Deprecation notice: 6 months advance warning MINOR: New features (backward compatible) → Example: v1.5.0 — New endpoint added → Action: Optional for consumers → Release: Bi-weekly PATCH: Bug fixes (backward compatible) → Example: v1.4.2 — Fix null pointer exception → Action: Recommended for all → Release: As needed VERSIONING STRATEGY: ═══════════════════════════════════════ Repository: Git tags (annotated) → git tag -a v1.5.0 -m "Release v1.5.0 — New search endpoint" → git push origin v1.5.0 CI/CD: → Main branch: Auto-increment patch version → Release branch: Set minor version → Major version: Manual approval Changelog: → Auto-generated from commit messages (conventional commits) → Formatted per Keep a Changelog standard ``` ### 3. Deployment Strategies ``` DEPLOYMENT STRATEGIES ═══════════════════════════════════════ Strategy Downtime Risk Rollback Use Case ─────────────────────────────────────────────────────────────────────── Blue-Green None LOW Instant Major releases Rolling None MEDIUM Gradual Standard releases Canary None LOW Gradual Risky changes Feature Flags None LOW Instant Feature testing Shadow None LOW N/A Validation Recreate Brief HIGH Quick Simple apps CANARY DEPLOYMENT: ═══════════════════════════════════════ Phase 1: Deploy to 1 server (5% traffic) → Monitor: Error rate, latency, custom metrics → Duration: 30 minutes → Criteria: No error increase, latency < threshold Phase 2: Expand to 25% traffic → Monitor: Business metrics (conversion, errors) → Duration: 1 hour → Criteria: No regression in business metrics Phase 3: Expand to 50% → 100% → Duration: 1 hour → Criteria: Stable metrics Rollback: Instant (switch traffic back to previous version) BLUE-GREEN DEPLOYMENT: ═══════════════════════════════════════ Blue (current): v1.4.2 (handling production traffic) Green (new): v1.5.0 (deployed, idle) Switch: 1. Deploy green environment 2. Run smoke tests on green 3. Switch load balancer → green 4. Monitor for 1 hour 5. Keep blue for rollback window (24 hours) 6. Decommission blue after window FEATURE FLAGS: ═══════════════════════════════════════ → LaunchDarkly / Split.io / custom → Flag types: Release, experiment, ops, kill switch → Targeting: Percentage, user attributes, groups → Rollout: Gradual (0% → 10% → 50% → 100%) → Kill switch: Immediate disable of problematic feature Flag lifecycle: → Create → Test → Rollout → Monitor → Cleanup (remove after 30 days) ``` ### 4. Release Communication ``` RELEASE NOTES TEMPLATE ═══════════════════════════════════════ # Release v1.5.0 — March 31, 2025 ## What's New → Advanced search with filters (Request ID: PROJ-456) → Bulk export to CSV (Request ID: PROJ-478) → Dark mode support (Request ID: PROJ-501) ## Improvements → 40% faster dashboard load time → Mobile-responsive design for settings page → Improved error messages ## Bug Fixes → Fixed: Calendar event not saving timezone → Fixed: Duplicate entries in user list → Fixed: PDF export formatting issue ## Breaking Changes → API: /v1/users endpoint deprecated (migrate to /v2/users) → API: Response format changed for /orders (see migration guide) ## Known Issues → Export large datasets (>10K rows) may time out (fix in v1.5.1) → Safari 14: Minor CSS rendering issue (workaround: use Safari 15+) ## Upgrade Instructions → Backend: Rolling update (zero downtime) → Frontend: Full deployment required → Database: Migration script included (auto-run) → Estimated time: 15 minutes RELEASE COMMUNICATION PLAN: ═══════════════════════════════════════ Pre-release (1 week before): → Email to stakeholders (release overview) → Slack announcement (#releases channel) → Update status page → Prepare FAQ Release day: → Live update in Slack (#release-war-room) → Status page update → Social media (if customer-facing) Post-release (1 week): → Success metrics report → Known issues update → Feedback collection ``` ### 5. Rollback Procedures ``` ROLLBACK PLAN ═══════════════════════════════════════ Rollback Triggers: ═══════════════════════════════════════ → Error rate increase > 2x baseline → P95 latency increase > 50% → Critical business metric drop (conversion, revenue) → Data corruption or loss → Security vulnerability discovered → Customer-reported critical issue Rollback Procedures by Deployment Type: ═══════════════════════════════════════ Blue-Green Rollback: → Switch load balancer back to blue → Time: <30 seconds → Data: No rollback needed (shared database) Rolling Rollback: → kubectl rollout undo deployment/ → Time: 2-5 minutes (depends on replica count) → Data: Database changes may need manual revert Feature Flag Rollback: → Toggle flag to off (LaunchDarkly console) → Time: <1 second (propagated in 30 seconds) → Data: Feature data preserved (can re-enable) DATABASE ROLLBACK: ═══════════════════════════════════════ → Migration scripts must be reversible → Down migration tested in staging → Data backup before migration → Rollback tested in staging before production Example: Up: ALTER TABLE users ADD COLUMN phone VARCHAR(20); Down: ALTER TABLE users DROP COLUMN phone; Risk: Data loss if phone was populated → use rename instead ``` ## Edge Cases - **Emergency hotfix**: Skip staging, deploy directly with approval - **Coordinated releases**: Multiple dependent services - **Long-running migrations**: Blue/green database strategy - **Customer notification**: Downtime communication - **Rollback window**: When to decommission previous version ## Integration Points - **CI/CD**: GitHub Actions, GitLab CI, Jenkins - **Feature flags**: LaunchDarkly, Split.io, custom - **Version control**: Git, GitHub, GitLab - **Communication**: Slack, email, status page - **Monitoring**: Prometheus, Grafana, Datadog - **Deployment**: ArgoCD, Flux, Spinnaker ## Output ### Release Summary ``` RELEASE v1.5.0 — March 31, 2025 ═══════════════════════════════════════ Type: Minor release Strategy: Canary (5% → 25% → 50% → 100%) Duration: 2 hours (from deploy to full rollout) Issues: 0 (smooth deployment) Rollback: N/A (no issues) Metrics: → Error rate: 0.02% (baseline: 0.02%) ✓ → P95 latency: 85ms (baseline: 90ms) ✓ → Uptime: 100% ✓ Next release: v1.5.1 (patch, April 15) ```