| name | release-manager |
| description | Use when the user asks to plan releases, manage changelogs, coordinate deployments, create release branches, or automate versioning. |
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
Key Components
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
Release Management Methodology
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 testing1.0.0-beta.2 - Beta releases for wider testing1.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-beta1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.11.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
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
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
Quality Gates
Documentation Requirements
Stakeholder Approvals
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
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
Best Practices
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
Common Anti-patterns
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.
