release-manager

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Release Manager

版本发布管理器

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

级别: POWERFUL
分类: 工程
领域: 软件发布管理 & 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.

Release Manager技能为端到端管理软件发布提供全面的工具和知识。从解析约定式提交到生成变更日志、确定版本升级幅度，再到编排发布流程，该技能确保软件发布可靠、可预测且文档完善。

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

基于约定式提交从git历史自动生成变更日志
基于提交分析和破坏性变更进行语义化版本升级
通过全面的检查清单和验证进行发布就绪性评估
附带利益相关者沟通模板的发布规划与协调
包含自动化恢复流程的回滚规划
针对紧急发布的热修复管理
用于渐进式发布的功能标志集成

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

changelog_generator.py - 解析git日志并生成结构化变更日志
version_bumper.py - 根据约定式提交确定正确的版本升级幅度
release_planner.py - 评估发布就绪性并生成协调计划

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

全面的发布管理方法论
约定式提交规范及示例
发布工作流对比（Git Flow、Trunk-based、GitHub Flow）
热修复流程与应急响应协议

Release Management Methodology

发布管理方法论

Semantic Versioning (SemVer)

语义化版本控制（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

语义化版本控制遵循MAJOR.MINOR.PATCH格式：

MAJOR 版本：当你做出不兼容的API变更时
MINOR 版本：当你以向后兼容的方式添加功能时
PATCH 版本：当你进行向后兼容的bug修复时

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

预发布版本通过添加连字符和标识符来表示：

```
1.0.0-alpha.1
```
- 用于早期测试的Alpha版本
```
1.0.0-beta.2
```
- 用于更广泛测试的Beta版本
```
1.0.0-rc.1
```
- 用于最终验证的候选发布版本

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
```

版本优先级通过比较每个标识符来确定：

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)]

<type>[可选范围]: <描述>

[可选正文]

[可选页脚]

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)

feat: 新功能（对应MINOR版本升级）
fix: bug修复（对应PATCH版本升级）
docs: 仅文档变更
style: 不影响代码含义的变更
refactor: 既不修复bug也不添加功能的代码变更
perf: 提升性能的代码变更
test: 添加缺失测试或修正现有测试
chore: 构建流程或辅助工具的变更
ci: CI配置文件和脚本的变更
build: 影响构建系统或外部依赖的变更
breaking: 引入破坏性变更（对应MAJOR版本升级）

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

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

结构

markdown

undefined

markdown

undefined

Changelog

[Unreleased]

Added

Changed

Deprecated

Removed

Fixed

Security

[1.2.0] - 2024-01-15

Added

OAuth2 authentication support (#123)
User preference dashboard (#145)

OAuth2 authentication support (#123)
User preference dashboard (#145)

Fixed

Race condition in user creation (#134)
Memory leak in image processing (#156)

Race condition in user creation (#134)
Memory leak in image processing (#156)

Breaking Changes

Removed legacy payment API

undefined

Removed legacy payment API

undefined

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

Added：新功能（feat）
Fixed：bug修复（fix）
Changed：现有功能的变更
Deprecated：即将移除的功能
Removed：已移除的功能
Security：漏洞修复

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

链接到拉取请求和问题：
```
(#123)
```
突出显示破坏性变更
基于范围的分组：
```
auth:
```
,
```
api:
```
,
```
ui:
```
协作者识别的Co-authored-by

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

MAJOR: 任何带有
```
BREAKING CHANGE
```
或类型后加
```
!
```
的提交
MINOR: 任何无破坏性变更的
```
feat
```
类型提交
PATCH:
```
fix
```
,
```
perf
```
,
```
security
```
类型提交
NO BUMP: 仅包含
```
docs
```
,
```
style
```
,
```
test
```
,
```
chore
```
,
```
ci
```
,
```
build
```
的提交

Pre-release Handling

预发布版本处理

python

undefined

python

undefined

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

undefined

undefined

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

对于包含多个包的单体仓库：

独立分析影响每个包的提交
支持范围化版本升级：
```
@scope/package@1.2.3
```
生成跨包的协调发布计划

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

main (生产环境) ← release/1.2.0 ← develop ← feature/login
                                           ← hotfix/critical-fix

优势:

职责清晰分离
稳定的main分支
并行功能开发
结构化的发布流程

流程:

从develop创建发布分支：
```
git checkout -b release/1.2.0 develop
```
完成发布准备（版本升级、变更日志）
合并到main和develop
标记发布：
```
git tag v1.2.0
```
从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

main ← feature/login (短期分支)
    ← feature/payment (短期分支)  
    ← hotfix/critical-fix

优势:

简化的工作流
更快的集成
减少合并冲突
适合持续集成

流程:

短期功能分支（1-3天）
频繁提交到main
为未完成功能使用功能标志
自动化测试关卡
使用功能开关从main部署

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

main ← feature/login
    ← hotfix/critical-fix

优势:

简单轻量
快速部署周期
适用于Web应用
最小化开销

流程:

从main创建功能分支
定期提交和推送
准备就绪时打开拉取请求
从功能分支部署进行测试
合并到main并部署

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

发布标志: 控制生产环境中的功能可见性
实验标志: A/B测试和渐进式发布
操作标志: 断路器和性能切换
权限标志: 基于角色的功能访问

Implementation Strategy

实现策略

python

undefined

python

undefined

Progressive rollout example

渐进式发布示例

if feature_flag("new_payment_flow", user_id): return new_payment_processor.process(payment) else: return legacy_payment_processor.process(payment)

undefined

if feature_flag("new_payment_flow", user_id): return new_payment_processor.process(payment) else: return legacy_payment_processor.process(payment)

undefined

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

内部利益相关者:

工程团队：技术变更和回滚流程
产品团队：功能描述和用户影响
支持团队：已知问题和故障排除指南
销售团队：面向客户的变更和沟通要点

外部沟通:

面向用户的发布说明
面向开发者的API变更日志
破坏性变更的迁移指南
适用时的停机通知

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

部署前（T-24h）：最终验证，冻结代码
数据库迁移（T-2h）：执行并验证架构变更
蓝绿部署（T-0）：逐步切换流量
部署后（T+1h）：监控指标和日志
回滚窗口期（T+4h）：回滚决策点

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

P0 - 关键: 系统完全中断、数据丢失、安全漏洞

服务级别协议（SLA）: 2小时内修复
流程: 紧急部署，全员参与
审批: 工程负责人 + 值班经理

P1 - 高: 主要功能故障，严重用户影响

SLA: 24小时内修复
流程: 加急审核和部署
审批: 工程负责人 + 产品经理

P2 - 中: 次要功能问题，有限用户影响

SLA: 在下一个发布周期修复
流程: 常规审核流程
审批: 标准拉取请求审核

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

错误率飙升: 30分钟内超过基线2倍
性能下降: 延迟增加超过50%
功能故障: 核心功能失效
安全事件: 漏洞被利用
数据损坏: 数据库完整性受损

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)

代码回滚:

回滚到之前的Docker镜像
仅兼容数据库的代码变更
优先禁用功能标志而非代码回滚

数据库回滚:

仅适用于非破坏性迁移
迁移前需备份数据
优先使用向前兼容的迁移（添加列，而非删除）

基础设施回滚:

蓝绿部署切换
负载均衡器配置回滚
DNS变更（传播时间较长）

Automated Rollback

自动化回滚

python

undefined

python

undefined

Example rollback automation

回滚自动化示例

def monitor_deployment(): if error_rate() > THRESHOLD: alert_oncall("Error rate spike detected") if auto_rollback_enabled(): execute_rollback()

undefined

def monitor_deployment(): if error_rate() > THRESHOLD: alert_oncall("Error rate spike detected") if auto_rollback_enabled(): execute_rollback()

undefined

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

回滚率: 被回滚的发布百分比
热修复率: 每常规发布的热修复次数
漏洞逃逸率: 每个发布的生产环境bug数量
检测时间: 问题被识别的速度

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

Git: 主要版本控制系统，支持约定式提交解析
GitHub/GitLab: 拉取请求自动化和CI/CD
Bitbucket: 流水线集成和部署关卡

CI/CD Platforms

CI/CD平台

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

Jenkins: 流水线编排和部署自动化
GitHub Actions: 工作流自动化和发布发布
GitLab CI: 集成流水线与环境管理
CircleCI: 基于容器的构建和部署

Monitoring & Alerting

监控与告警

DataDog: Application performance monitoring
New Relic: Error tracking and performance insights
Sentry: Error aggregation and release tracking
PagerDuty: Incident response and escalation

DataDog: 应用性能监控
New Relic: 错误跟踪和性能洞察
Sentry: 错误聚合和发布跟踪
PagerDuty: 事件响应和升级

Communication Platforms

沟通平台

Slack: Release notifications and coordination
Microsoft Teams: Stakeholder communication
Email: External customer notifications
Status Pages: Public incident communication

Slack: 发布通知和协调
Microsoft Teams: 利益相关者沟通
Email: 外部客户通知
状态页面: 公开事件沟通

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

定期节奏: 建立可预测的发布时间表
功能冻结: 发布前48小时锁定变更
风险评估: 评估变更的潜在影响
利益相关者对齐: 确保所有团队做好准备

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.

评估: 评估当前发布流程和痛点
工具设置: 为你的仓库配置脚本
流程定义: 为团队选择合适的工作流
自动化: 实现CI/CD流水线和质量关卡
培训: 向团队传授新流程和工具
监控: 设置发布指标和告警
迭代: 根据反馈和指标持续改进

Release Manager技能将混乱的部署转变为可预测、可靠的发布，为整个组织建立信心。