IT AI Skill

Software Release Management

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 handlin...

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/<name>
  → 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)