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.

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

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:

约定式提交为commit消息提供了结构化格式，可支撑自动化工具链运行：

Format

格式

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

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

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

关联PR和issue链接：
```
(#123)
```
突出显示破坏性变更
基于作用域分组：
```
auth:
```
、
```
api:
```
、
```
ui:
```
标注共同贡献者信息

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
```
类型提交
不升级：仅包含
```
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

对于包含多个包的monorepo：

独立分析影响每个包的提交
支持作用域版本升级：
```
@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 (production) ← 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

Trunk-based开发

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 (short-lived)
    ← feature/payment (short-lived)  
    ← 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应用
overhead低

流程：

从main创建功能分支
定期提交推送
准备就绪后提交PR
从功能分支部署测试
合并到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）：执行并校验schema变更
蓝绿部署（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：下个发布周期修复
流程：正常评审流程
审批：标准PR评审

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变更（ propagation时间更长）

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逃逸率：每个版本发布后出现的生产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

评审时长：代码评审花费的时间
测试时长：自动化+人工测试总耗时
审批周期：从PR提交到合并的时间
发布准备时长：发布相关活动的总耗时

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：主流VCS，支持约定式提交解析
GitHub/GitLab：PR自动化和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

固定节奏：建立可预测的发布 schedule
功能冻结：发布前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

清晰 timeline：提前同步发布 schedule
定期更新：发布过程中同步状态
问题透明：坦诚沟通出现的问题
复盘：从事件中学习优化流程

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

** blame文化**：害怕变更或上报问题
英雄文化：依赖个人而非流程
完美主义：为 minor 优化延迟发布
风险厌恶：因为害怕问题回避必要变更

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流水线和质量卡点
培训：向团队培训新流程和工具
监控：配置发布相关指标和告警
迭代：基于反馈和指标持续优化

发布管理器技能可将混乱的部署转变为可预测、可靠的发布，提升整个组织的发布信心。