release-manager

Release Manager

Tier: POWERFUL Category: Engineering Domain: Software Release Management & DevOps

Overview

The Release Manager skill provides comprehensive tools and knowledge for managing software releases end-to-end. From parsing conventional commits to generating changelogs, determining version bumps, and orchestrating release processes, this skill ensures reliable, predictable, and well-documented software releases.

Core Capabilities

Automated Changelog Generation from git history using conventional commits Semantic Version Bumping based on commit analysis and breaking changes Release Readiness Assessment with comprehensive checklists and validation Release Planning & Coordination with stakeholder communication templates Rollback Planning with automated recovery procedures Hotfix Management for emergency releases Feature Flag Integration for progressive rollouts

Scripts

changelog_generator.py - Parses git logs and generates structured changelogs version_bumper.py - Determines correct version bumps from conventional commits release_planner.py - Assesses release readiness and generates coordination plans

Documentation

Comprehensive release management methodology Conventional commits specification and examples Release workflow comparisons (Git Flow, Trunk-based, GitHub Flow) Hotfix procedures and emergency response protocols

Semantic Versioning (SemVer)

Semantic Versioning follows the MAJOR.MINOR.PATCH format where: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backwards compatible manner PATCH version when you make backwards compatible bug fixes Pre-release Versions Pre-release versions are denoted by appending a hyphen and identifiers: 1.0.0-alpha.1 - Alpha releases for early testing 1.0.0-beta.2 - Beta releases for wider testing 1.0.0-rc.1 - Release candidates for final validation Version Precedence Version precedence is determined by comparing each identifier: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 1.0.0-rc.1 < 1.0.0

Conventional Commits

Conventional Commits provide a structured format for commit messages that enables automated tooling: Format <type>[optional scope]: <description> [optional body] [optional footer(s)] Types feat: A new feature (correlates with MINOR version bump) fix: A bug fix (correlates with PATCH version bump) docs: Documentation only changes style: Changes that do not affect the meaning of the code refactor: A code change that neither fixes a bug nor adds a feature perf: A code change that improves performance test: Adding missing tests or correcting existing tests chore: Changes to the build process or auxiliary tools ci: Changes to CI configuration files and scripts build: Changes that affect the build system or external dependencies breaking: Introduces a breaking change (correlates with MAJOR version bump) Examples feat(user-auth): add OAuth2 integration fix(api): resolve race condition in user creation docs(readme): update installation instructions feat!: remove deprecated payment API BREAKING CHANGE: The legacy payment API has been removed

Automated Changelog Generation

• Changelogs are automatically generated from conventional commits, organized by:
• Structure
• # Changelog
• ## [Unreleased]
• ### Added
• ### Changed
• ### Deprecated
• ### Removed
• ### Fixed
• ### Security
• ## [1.2.0] - 2024-01-15
• ### Added
• OAuth2 authentication support (#123)
• User preference dashboard (#145)
• ### Fixed
• Race condition in user creation (#134)
• Memory leak in image processing (#156)
• ### Breaking Changes
• Removed legacy payment API
• Grouping Rules
• Added for new features (feat)
• Fixed for bug fixes (fix)
• Changed for changes in existing functionality
• Deprecated for soon-to-be removed features
• Removed for now removed features
• Security for vulnerability fixes
• Metadata Extraction
• Link to pull requests and issues: (#123)
• Breaking changes highlighted prominently
• Scope-based grouping: auth:, api:, ui:
• Co-authored-by for contributor recognition

Version Bump Strategies

Version bumps are determined by analyzing commits since the last release: Automatic Detection Rules MAJOR: Any commit with BREAKING CHANGE or ! after type MINOR: Any feat type commits without breaking changes PATCH: fix, perf, security type commits NO BUMP: docs, style, test, chore, ci, build only Pre-release Handling # Alpha: 1.0.0-alpha.1 → 1.0.0-alpha.2 # Beta: 1.0.0-alpha.5 → 1.0.0-beta.1 # RC: 1.0.0-beta.3 → 1.0.0-rc.1 # Release: 1.0.0-rc.2 → 1.0.0 Multi-package Considerations For monorepos with multiple packages: Analyze commits affecting each package independently Support scoped version bumps: @scope/package@1.2.3 Generate coordinated release plans across packages

Release Branch Workflows

Git Flow main (production) ← release/1.2.0 ← develop ← feature/login ← hotfix/critical-fix Advantages: Clear separation of concerns Stable main branch Parallel feature development Structured release process Process: Create release branch from develop: git checkout -b release/1.2.0 develop Finalize release (version bump, changelog) Merge to main and develop Tag release: git tag v1.2.0 Deploy from main Trunk-based Development main ← feature/login (short-lived) ← feature/payment (short-lived) ← hotfix/critical-fix Advantages: Simplified workflow Faster integration Reduced merge conflicts Continuous integration friendly Process: Short-lived feature branches (1-3 days) Frequent commits to main Feature flags for incomplete features Automated testing gates Deploy from main with feature toggles GitHub Flow main ← feature/login ← hotfix/critical-fix Advantages: Simple and lightweight Fast deployment cycle Good for web applications Minimal overhead Process: Create feature branch from main Regular commits and pushes Open pull request when ready Deploy from feature branch for testing Merge to main and deploy

Feature Flag Integration

Feature flags enable safe, progressive rollouts: Types of Feature Flags Release flags: Control feature visibility in production Experiment flags: A/B testing and gradual rollouts Operational flags: Circuit breakers and performance toggles Permission flags: Role-based feature access Implementation Strategy # Progressive rollout example if feature_flag("new_payment_flow", user_id): return new_payment_processor.process(payment) else: return legacy_payment_processor.process(payment) Release Coordination Deploy code with feature behind flag (disabled) Gradually enable for percentage of users Monitor metrics and error rates Full rollout or quick rollback based on data Remove flag in subsequent release

Release Readiness Checklists

Pre-Release Validation All planned features implemented and tested Breaking changes documented with migration guide API documentation updated Database migrations tested Security review completed for sensitive changes Performance testing passed thresholds Internationalization strings updated Third-party integrations validated Quality Gates Unit test coverage ≥ 85% Integration tests passing End-to-end tests passing Static analysis clean Security scan passed Dependency audit clean Load testing completed Documentation Requirements CHANGELOG.md updated README.md reflects new features API documentation generated Migration guide written for breaking changes Deployment notes prepared Rollback procedure documented Stakeholder Approvals Product Manager sign-off Engineering Lead approval QA validation complete Security team clearance Legal review (if applicable) Compliance check (if regulated)

Deployment Coordination

Communication Plan Internal Stakeholders: Engineering team: Technical changes and rollback procedures Product team: Feature descriptions and user impact Support team: Known issues and troubleshooting guides Sales team: Customer-facing changes and talking points External Communication: Release notes for users API changelog for developers Migration guide for breaking changes Downtime notifications if applicable Deployment Sequence Pre-deployment (T-24h): Final validation, freeze code Database migrations (T-2h): Run and validate schema changes Blue-green deployment (T-0): Switch traffic gradually Post-deployment (T+1h): Monitor metrics and logs Rollback window (T+4h): Decision point for rollback Monitoring & Validation Application health checks Error rate monitoring Performance metrics tracking User experience monitoring Business metrics validation Third-party service integration health

Hotfix Procedures

Hotfixes address critical production issues requiring immediate deployment: Severity Classification P0 - Critical: Complete system outage, data loss, security breach SLA: Fix within 2 hours Process: Emergency deployment, all hands on deck Approval: Engineering Lead + On-call Manager P1 - High: Major feature broken, significant user impact SLA: Fix within 24 hours Process: Expedited review and deployment Approval: Engineering Lead + Product Manager P2 - Medium: Minor feature issues, limited user impact SLA: Fix in next release cycle Process: Normal review process Approval: Standard PR review Emergency Response Process Incident declaration: Page on-call team Assessment: Determine severity and impact Hotfix branch: Create from last stable release Minimal fix: Address root cause only Expedited testing: Automated tests + manual validation Emergency deployment: Deploy to production Post-incident: Root cause analysis and prevention

Rollback Planning

Every release must have a tested rollback plan: Rollback Triggers Error rate spike: >2x baseline within 30 minutes Performance degradation: >50% latency increase Feature failures: Core functionality broken Security incident: Vulnerability exploited Data corruption: Database integrity compromised Rollback Types Code Rollback: Revert to previous Docker image Database-compatible code changes only Feature flag disable preferred over code rollback Database Rollback: Only for non-destructive migrations Data backup required before migration Forward-only migrations preferred (add columns, not drop) Infrastructure Rollback: Blue-green deployment switch Load balancer configuration revert DNS changes (longer propagation time) Automated Rollback # Example rollback automation def monitor_deployment(): if error_rate() > THRESHOLD: alert_oncall("Error rate spike detected") if auto_rollback_enabled(): execute_rollback()

Release Metrics & Analytics

Key Performance Indicators Lead Time: From commit to production Deployment Frequency: Releases per week/month Mean Time to Recovery: From incident to resolution Change Failure Rate: Percentage of releases causing incidents Quality Metrics Rollback Rate: Percentage of releases rolled back Hotfix Rate: Hotfixes per regular release Bug Escape Rate: Production bugs per release Time to Detection: How quickly issues are identified Process Metrics Review Time: Time spent in code review Testing Time: Automated + manual testing duration Approval Cycle: Time from PR to merge Release Preparation: Time spent on release activities

Tool Integration

Version Control Systems Git: Primary VCS with conventional commit parsing GitHub/GitLab: Pull request automation and CI/CD Bitbucket: Pipeline integration and deployment gates CI/CD Platforms Jenkins: Pipeline orchestration and deployment automation GitHub Actions: Workflow automation and release publishing GitLab CI: Integrated pipelines with environment management CircleCI: Container-based builds and deployments Monitoring & Alerting DataDog: Application performance monitoring New Relic: Error tracking and performance insights Sentry: Error aggregation and release tracking PagerDuty: Incident response and escalation Communication Platforms Slack: Release notifications and coordination Microsoft Teams: Stakeholder communication Email: External customer notifications Status Pages: Public incident communication

Release Planning

Regular cadence: Establish predictable release schedule Feature freeze: Lock changes 48h before release Risk assessment: Evaluate changes for potential impact Stakeholder alignment: Ensure all teams are prepared

Quality Assurance

Automated testing: Comprehensive test coverage Staging environment: Production-like testing environment Canary releases: Gradual rollout to subset of users Monitoring: Proactive issue detection

Communication

Clear timelines: Communicate schedules early Regular updates: Status reports during release process Issue transparency: Honest communication about problems Post-mortems: Learn from incidents and improve

Automation

Reduce manual steps: Automate repetitive tasks Consistent process: Same steps every time Audit trails: Log all release activities Self-service: Enable teams to deploy safely

Process Anti-patterns

Manual deployments: Error-prone and inconsistent Last-minute changes: Risk introduction without proper testing Skipping testing: Deploying without validation Poor communication: Stakeholders unaware of changes

Technical Anti-patterns

Monolithic releases: Large, infrequent releases with high risk Coupled deployments: Services that must be deployed together No rollback plan: Unable to quickly recover from issues Environment drift: Production differs from staging

Cultural Anti-patterns

Blame culture: Fear of making changes or reporting issues Hero culture: Relying on individuals instead of process Perfectionism: Delaying releases for minor improvements Risk aversion: Avoiding necessary changes due to fear

Getting Started

Assessment: Evaluate current release process and pain points Tool setup: Configure scripts for your repository Process definition: Choose appropriate workflow for your team Automation: Implement CI/CD pipelines and quality gates Training: Educate team on new processes and tools Monitoring: Set up metrics and alerting for releases Iteration: Continuously improve based on feedback and metrics The Release Manager skill transforms chaotic deployments into predictable, reliable releases that build confidence across your entire organization.