chore: import zh skill release-manager
This commit is contained in:
wehub-skill-sync
@@ -0,0 +1,9 @@
|
||||
# WeHub 来源说明
|
||||
|
||||
- Skill 名称：`release-manager`
|
||||
- 中文类目：从 git 提交自动生成 changelog 和 semver
|
||||
- 上游仓库：`alirezarezvani__claude-skills`
|
||||
- 上游路径：`.gemini/skills/release-manager/SKILL.md`
|
||||
- 上游链接：https://github.com/alirezarezvani/claude-skills/blob/HEAD/.gemini/skills/release-manager/SKILL.md
|
||||
- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理
|
||||
- 原作者、版权和许可证信息以上游仓库为准
|
||||
@@ -0,0 +1,490 @@
|
||||
---
|
||||
name: "release-manager"
|
||||
description: "当用户要求计划发布、管理变更日志、协调部署、创建发布分支或自动化版本管理时使用。"
|
||||
---
|
||||
|
||||
# 发布管理器
|
||||
|
||||
**层级：** 强大
|
||||
**分类：** 工程
|
||||
**领域：** 软件发布管理与 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 已被移除
|
||||
```
|
||||
|
||||
### 自动变更日志生成
|
||||
|
||||
变更日志从常规提交中自动生成，并按以下结构组织：
|
||||
|
||||
#### 结构
|
||||
```markdown
|
||||
# 变更日志
|
||||
|
||||
## [未发布]
|
||||
### 新增
|
||||
### 变更
|
||||
### 弃用
|
||||
### 移除
|
||||
### 修复
|
||||
### 安全
|
||||
|
||||
## [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` 类型
|
||||
|
||||
#### 预发布处理
|
||||
```python
|
||||
# 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 测试和逐步发布
|
||||
- **运维开关**：熔断器和性能开关
|
||||
- **权限开关**：基于角色的特性访问
|
||||
|
||||
#### 实现策略
|
||||
```python
|
||||
# 渐进式发布示例
|
||||
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 变更（传播时间较长）
|
||||
|
||||
#### 自动回滚
|
||||
```python
|
||||
# 回滚自动化示例
|
||||
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. **迭代**：基于反馈和指标持续改进
|
||||
|
||||
发布管理器技能将混乱的部署转变为可预测、可靠的发布，从而在整个组织中建立信心。
|
||||
Reference in New Issue
Block a user