/SKILL.md

name, description

name	description
release-manager	当用户要求计划发布、管理变更日志、协调部署、创建发布分支或自动化版本管理时使用。

发布管理器

层级： 强大
分类： 工程
领域： 软件发布管理与 DevOps

概述

发布管理器技能提供了一套全面的工具和知识，用于端到端地管理软件发布。从解析常规提交到生成变更日志、确定版本升级以及编排发布流程，该技能确保软件发布可靠、可预测且文档完善。

核心能力

• 自动变更日志生成：基于使用常规提交的 git 历史记录生成
• 语义化版本升级：基于提交分析和破坏性变更进行
• 发布就绪评估：提供全面的检查清单和验证
• 发布规划与协调：附带干系人沟通模板
• 回滚规划：附带自动化恢复流程
• 热修复管理：用于紧急发布
• 特性开关集成：用于渐进式发布

关键组件

脚本

1. changelog_generator.py - 解析 git 日志并生成结构化的变更日志
2. version_bumper.py - 根据常规提交确定正确的版本升级
3. release_planner.py - 评估发布就绪状态并生成协调计划

文档

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

发布管理方法论

语义化版本控制（SemVer）

语义化版本控制采用 MAJOR.MINOR.PATCH 格式，其中：

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

预发布版本

预发布版本通过在版本号后附加连字符和标识符来表示：

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

版本优先级

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

1. 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta
2. 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1
3. 1.0.0-rc.1 < 1.0.0

常规提交

常规提交提供了一种结构化的提交消息格式，支持自动化工具：

格式

<类型>[可选范围]: <描述>

[可选正文]

[可选脚注]

类型

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

示例

feat(user-auth): 添加 OAuth2 集成

fix(api): 解决用户创建中的竞态条件

docs(readme): 更新安装说明

feat!: 移除已弃用的支付 API
BREAKING CHANGE: 旧版支付 API 已被移除

自动变更日志生成

变更日志从常规提交中自动生成，并按以下结构组织：

结构

# 变更日志

## [未发布]
### 新增
### 变更
### 弃用
### 移除
### 修复
### 安全

## [1.2.0] - 2024-01-15
### 新增
- OAuth2 认证支持 (#123)
- 用户偏好面板 (#145)

### 修复
- 用户创建中的竞态条件 (#134)
- 图片处理中的内存泄漏 (#156)

### 破坏性变更
- 移除了旧版支付 API

分组规则

• 新增：用于新功能（feat）
• 修复：用于缺陷修复（fix）
• 变更：用于现有功能的变更
• 弃用：用于即将被移除的功能
• 移除：用于已被移除的功能
• 安全：用于漏洞修复

元数据提取

• 关联拉取请求和议题：(#123)
• 突出显示破坏性变更
• 按范围分组：auth:、api:、ui:
• 联合作者署名用于贡献者致谢

版本升级策略

版本升级通过分析自上次发布以来的提交记录来确定：

自动检测规则

1. MAJOR：任何包含 BREAKING CHANGE 或在类型后带有 ! 的提交
2. MINOR：任何不含破坏性变更的 feat 类型提交
3. PATCH：fix、perf、security 类型提交
4. 不升级：仅包含 docs、style、test、chore、ci、build 类型

预发布处理

# 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
# 发布: 1.0.0-rc.2 → 1.0.0

多包考量

对于包含多个包的 monorepo：

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

发布分支工作流

Git Flow

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

优势：

• 职责划分清晰
• 主分支稳定
• 并行特性开发
• 结构化的发布流程

流程：

1. 从 develop 创建发布分支：git checkout -b release/1.2.0 develop
2. 完成发布（版本升级、变更日志）
3. 合并到 main 和 develop
4. 打标签：git tag v1.2.0
5. 从 main 部署

基于主干开发（Trunk-based Development）

main ← feature/login（短期存在）
    ← feature/payment（短期存在）
    ← hotfix/critical-fix

优势：

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

流程：

1. 短期特性分支（1-3 天）
2. 频繁提交到 main
3. 使用特性开关管理未完成功能
4. 自动化测试关卡
5. 从 main 部署，通过特性开关控制

GitHub Flow

main ← feature/login
    ← hotfix/critical-fix

优势：

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

流程：

1. 从 main 创建特性分支
2. 定期提交和推送
3. 准备就绪后开启拉取请求
4. 从特性分支部署用于测试
5. 合并到 main 并部署

特性开关集成

特性开关支持安全、渐进式的发布：

特性开关类型

• 发布开关：控制特性在生产环境中的可见性
• 实验开关：A/B 测试和逐步发布
• 运维开关：熔断器和性能开关
• 权限开关：基于角色的特性访问

实现策略

# 渐进式发布示例
if feature_flag("new_payment_flow", user_id):
    return new_payment_processor.process(payment)
else:
    return legacy_payment_processor.process(payment)

发布协调

1. 部署代码时特性处于开关控制下（已禁用）
2. 逐步对一定比例的用户启用
3. 监控指标和错误率
4. 根据数据决定全面发布或快速回滚
5. 在后续发布中移除开关

发布就绪检查清单

发布前验证

• 所有计划中的特性已实现并通过测试
• 破坏性变更已记录并附带迁移指南
• API 文档已更新
• 数据库迁移已测试
• 敏感变更已完成安全审查
• 性能测试已达到阈值
• 国际化字符串已更新
• 第三方集成已验证

质量关卡

• 单元测试覆盖率 ≥ 85%
• 集成测试通过
• 端到端测试通过
• 静态分析无问题
• 安全扫描通过
• 依赖审计无问题
• 负载测试已完成

文档要求

• CHANGELOG.md 已更新
• README.md 反映了新特性
• API 文档已生成
• 破坏性变更已编写迁移指南
• 部署说明已准备
• 回滚流程已记录

干系人审批

• 产品经理签字确认
• 工程负责人批准
• QA 验证完成
• 安全团队许可
• 法务审核（如适用）
• 合规检查（如受监管）

部署协调

沟通计划

内部干系人：

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

外部沟通：

• 面向用户的发布说明
• 面向开发者的 API 变更日志
• 破坏性变更的迁移指南
• 如有必要，发布停机通知

部署顺序

1. 部署前（T-24h）：最终验证，冻结代码
2. 数据库迁移（T-2h）：运行并验证 schema 变更
3. 蓝绿部署（T-0）：逐步切换流量
4. 部署后（T+1h）：监控指标和日志
5. 回滚窗口（T+4h）：决定是否回滚

监控与验证

• 应用健康检查
• 错误率监控
• 性能指标跟踪
• 用户体验监控
• 业务指标验证
• 第三方服务集成健康检查

热修复流程

热修复用于处理需要立即部署的关键生产环境问题：

严重等级分类

P0 - 关键：系统完全宕机、数据丢失、安全漏洞

• SLA：2 小时内修复
• 流程：紧急部署，全员投入
• 审批：工程负责人 + 值班经理

P1 - 高：主要功能损坏，对用户影响严重

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

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

• SLA：在下一个发布周期修复
• 流程：正常审查流程
• 审批：标准 PR 审查

应急响应流程

1. 事件声明：通知值班团队
2. 评估：确定严重等级和影响范围
3. 热修复分支：从最后一个稳定版本创建
4. 最小修复：仅处理根本原因
5. 加急测试：自动化测试 + 手动验证
6. 紧急部署：部署到生产环境
7. 事后处理：根因分析及预防措施

回滚规划

每个发布版本都必须有经过测试的回滚计划：

回滚触发条件

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

回滚类型

代码回滚：

• 恢复到上一个 Docker 镜像
• 仅回滚与数据库兼容的代码变更
• 优先使用特性开关禁用而非代码回滚

数据库回滚：

• 仅适用于非破坏性迁移
• 迁移前需要备份数据
• 优先使用仅向前迁移（新增列，而非删除列）

基础设施回滚：

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

自动回滚

# 回滚自动化示例
def monitor_deployment():
    if error_rate() > THRESHOLD:
        alert_oncall("检测到错误率飙升")
        if auto_rollback_enabled():
            execute_rollback()

发布指标与分析

关键绩效指标

• 交付周期：从提交到生产环境的时间
• 部署频率：每周/月的发布次数
• 平均恢复时间：从事件到解决的时间
• 变更失败率：导致事故的发布比例

质量指标

• 回滚率：被回滚的发布比例
• 热修复率：每常规发布的热修复次数
• 缺陷逃逸率：每发布的生产环境缺陷数
• 检测时间：问题被识别的速度

流程指标

• 审查时间：代码审查耗时
• 测试时间：自动化 + 手动测试时长
• 审批周期：从 PR 到合并的时间
• 发布准备：发布活动耗时

工具集成

版本控制系统

• Git：主要的 VCS，支持常规提交解析
• GitHub/GitLab：拉取请求自动化和 CI/CD
• Bitbucket：流水线集成和部署关卡

CI/CD 平台

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

监控与告警

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

沟通平台

• Slack：发布通知和协调
• Microsoft Teams：干系人沟通
• 电子邮件：外部客户通知
• 状态页面：公开事件沟通

最佳实践

发布规划

1. 固定节奏：建立可预测的发布计划
2. 特性冻结：发布前 48 小时锁定变更
3. 风险评估：评估变更的潜在影响
4. 干系人对齐：确保所有团队准备就绪

质量保证

1. 自动化测试：全面的测试覆盖
2. 预发布环境：类似生产环境的测试环境
3. 金丝雀发布：逐步向部分用户发布
4. 监控：主动发现问题

沟通

1. 清晰的时间线：尽早沟通计划
2. 定期更新：发布过程中的状态报告
3. 问题透明：诚实地沟通问题
4. 事后复盘：从事件中学习并改进

自动化

1. 减少手动步骤：自动化重复性任务
2. 一致的流程：每次执行相同的步骤
3. 审计追踪：记录所有发布活动
4. 自助服务：让团队能够安全地自行部署

常见反模式

流程反模式

• 手动部署：容易出错且不一致
• 临门一脚的变更：未经充分测试就引入风险
• 跳过测试：未经验证就部署
• 沟通不畅：干系人不知晓变更

技术反模式

• 单体发布：大规模、低频率的高风险发布
• 耦合部署：必须同时部署的服务
• 无回滚计划：无法快速从问题中恢复
• 环境漂移：生产环境与预发布环境不一致

文化反模式

• 追责文化：害怕进行变更或报告问题
• 英雄文化：依赖个人而非流程
• 完美主义：因小幅改进而延迟发布
• 风险规避：因恐惧而回避必要的变更

快速入门

1. 评估：评估当前的发布流程和痛点
2. 工具设置：为您的仓库配置脚本
3. 流程定义：为您的团队选择合适的工作流
4. 自动化：实施 CI/CD 流水线和质量关卡
5. 培训：让团队了解新流程和工具
6. 监控：为发布设置指标和告警
7. 迭代：基于反馈和指标持续改进

发布管理器技能将混乱的部署转变为可预测、可靠的发布，从而在整个组织中建立信心。