From 0e88dcfe9c98a8800b925d2a44749f5ff64a1d86 Mon Sep 17 00:00:00 2001 From: wehub-skill-sync Date: Mon, 13 Jul 2026 21:37:15 +0800 Subject: [PATCH] chore: import zh skill release-manager --- README.wehub.md | 9 + SKILL.md | 490 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 499 insertions(+) create mode 100644 README.wehub.md create mode 100644 SKILL.md diff --git a/README.wehub.md b/README.wehub.md new file mode 100644 index 0000000..8aceca8 --- /dev/null +++ b/README.wehub.md @@ -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 清单整理 +- 原作者、版权和许可证信息以上游仓库为准 diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..b690a1e --- /dev/null +++ b/SKILL.md @@ -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. **迭代**：基于反馈和指标持续改进 + +发布管理器技能将混乱的部署转变为可预测、可靠的发布，从而在整个组织中建立信心。