release-engineering

发布工程

面向高级到首席级别的发布工程方法：设计并运营流水线、流程、制品、关卡、合规证据和指标，让软件安全、可预测且快速地从提交交付给客户。

职责范围

你负责	你不负责
发布流程设计——分支策略、流程模型、发布节奏	应用功能实现——请转至 backend-engineering / frontend-engineering
CD 流水线架构——一次构建、多阶段晋级、关卡、通过后推送	生产环境事故的根因调试——请转至 systematic-debugging
渐进式交付——金丝雀发布、分环发布、按百分比逐步推出、功能标志	值班和 SLO 运营——请转至 site-reliability-engineering
版本控制与制品——SemVer、约定式提交、变更日志、不可变性、来源证明	安全实现和威胁建模——请转至 secure-software-engineering
发布就绪度与质量关卡——候选版本、是否发布决策、签核	内部开发者平台构建——请转至 platform-engineering
回滚与恢复规划——运行手册、演练、恢复目标	数据流水线运营和架构迁移工程——请转至 data-engineering
变更治理与审计合规——SOC 2 / SOX / PCI 证据链	规范编写和 SDD 关卡机制——请转至 spec-driven-development
DORA 指标——定义、计算、阈值	API 契约设计和版本控制策略——请转至 api-design-and-evolution
多团队发布协调——发布列车、日历、稳定化	根据明确标准收集证据并做出判定——请转至 verification-methodology
发布运营——切分支、流水线故障排查、紧急发布	运行时监控和告警——这属于 SRE

核心原则

一次构建，多次晋级。 通过所有关卡的制品，就是唯一交付的制品。按环境重新构建会重新引入风险，并使已验证的内容失去效力。

小批量发布更快、更安全。 与长期存续的分支相比，基于主干的开发配合频繁的小规模合并，在所有 DORA 指标上都更出色——部署频率、前置时间、变更失败率和恢复时间。

将部署与发布解耦。 将代码部署到生产环境，不等于向用户开放代码。功能标志和渐进式发布将二者分开，使其能够按各自的时间线进行，并且可以独立撤销。

自动化安全措施胜过审批官僚主义。 基于证据的控制措施和流水线关卡，优于变更咨询委员会的签核；研究表明，后者会降低交付速度和稳定性。将检查自动化；仅对真正特殊的变更保留人工审批。

演练回滚。 未经演练的回滚会在压力下失败。回滚是一级发布制品，拥有自己的运行手册、触发阈值和演练日志。

在生产环境中验证。 预发布环境的一致性有帮助，但真正证明就绪度的是生产金丝雀、冒烟测试和可观测性关卡。真实流量、真实遥测、真实决策节点。

保护供应链。 为每个制品签名，记录来源证明和 SBOM 数据，并将制品仓库视为安全边界。完整性是发布的一部分，而非附加项。

DORA 是系统层面的结果。 速度和稳定性源于流程设计方式——批量大小、架构、自动化、安全文化——而不是追逐指标目标。

加载指南

文件	加载时机
references/role-and-career.md	了解发布工程师的角色——组织归属、日常工作、Senior/Staff/Principal 职级，以及区分各级别的依据
references/skills-competency-model.md	梳理发布工程师需要掌握的技术与专业技能，以及哪些技能能让 Senior 及以上级别脱颖而出
references/release-process-models.md	选择流程模型——主干开发、GitFlow、GitHub Flow、发布分支、发布列车——并使发布节奏与组织相匹配
references/cd-and-pipeline-stages.md	设计 CD 流水线——一次构建、多阶段晋级、阶段关卡、绿色后推送、流水线即代码、无环境依赖构建、环境一致性
references/progressive-delivery.md	规划金丝雀、蓝绿、分批或按百分比发布；设置指标和错误预算关卡；配置自动回滚触发条件
references/change-governance-and-compliance.md	构建满足审计要求的变更控制——SOC 2 CC8.1、SOX ITGC、PCI 回退、证据链、职责分离、紧急变更
references/readiness-and-quality-gates.md	定义就绪度维度、发布候选版本、上线/不上线决策机制、错误预算发布策略和完成定义
references/rollback-and-recovery.md	根据系统类型规划回滚、向前修复或标记恢复；演练回滚；设定限时决策；隔离
references/versioning-and-artifacts.md	制定 SemVer/CalVer 策略、约定式提交和变更日志规范，以及制品不可变性和来源证明
references/feature-flag-lifecycle.md	管理标记的完整生命周期——创建、保护、发布、验证、移除、过期——并避免标记债务
references/monorepo-polyrepo-release.md	选择单体仓库或多仓库发布策略、检测受影响的构建、确定拓扑发布顺序和发布工具
references/toolchain-landscape.md	按类别选择工具——CI/CD、发布自动化、制品仓库、GitOps、功能标记（2025-2026 年状态）
references/supply-chain-security.md	加固供应链——SLSA、SBOM、sigstore 无密钥签名、依赖项更新、来源证明声明
references/metrics-and-dora.md	定义并计算五项 DORA 指标，了解阈值、供应商差异和衡量误区
references/release-operations-and-triage.md	端到端管理发布列车——切分分支、稳定化、上线/不上线决策、流水线分诊、发布基础设施可靠性、Agent 自动化
templates/release-plan.md	制定发布计划——范围、里程碑、负责人、风险、发布、回滚预案、沟通
templates/release-readiness-checklist.md	开展就绪度评审——按维度列出复选框表格并注明负责人和证据，以及上线/不上线决策区块
templates/rollback-runbook.md	编写回滚操作手册——触发条件、各层步骤、验证、顺序、沟通、演练日志
templates/release-notes.md	起草发布说明——版本、日期、按变更类型划分的章节、破坏性变更、迁移步骤
templates/change-governance-record.md	记录满足审计要求的变更——工单、PR、CI 运行记录、制品摘要、部署时间戳、验证、紧急标记
templates/hotfix-emergency-release-plan.md	规划紧急发布——严重级别、紧急授权审批、加急流程、实施后评审
assets/dora-metrics-reference.md	一页查阅五项 DORA 指标——公式、单位、数据来源、阈值、误区
assets/versioning-decision-table.md	选择版本方案——SemVer、CalVer、独立版本或统一版本，以及递增规则
assets/deployment-strategy-matrix.md	比较部署策略——滚动、蓝绿、金丝雀、分批、标记、影子部署——考量速度、安全性和回滚
assets/release-toolchain-cheatsheet.md	按类别快速查找工具——每种工具的简短说明及适用场景
scripts/version_bump.py	根据约定式提交或 git 范围计算下一个 SemVer 版本
scripts/semver_check.py	校验、比较或排序严格遵循 SemVer 的版本
scripts/changelog_check.py	校验 Keep a Changelog 或 Release Please 的 CHANGELOG.md 文件
scripts/dora_metrics.py	根据部署和提交事件数据计算五项 DORA 指标
scripts/release_plan_scaffold.py	根据标记或 git 范围搭建发布计划文档框架
evals/evals.json	运行此技能的输出质量评估（架构 v1，8 个用例）

相关技能

• 使用 qa-methodology 定义测试策略、回归范围、易波动测试政策和质量门禁语义。本技能会将其产生的证据与运维和治理证据结合起来，为发布决策提供依据。
• 对于 AI Agent 发布，使用 agent-evals-and-observability 设计并解读行为、轨迹和模型回归证据，然后将其纳入发布门禁。

脚本

脚本	调用方式	用途
version_bump	python3 scripts/version_bump.py --current-version 1.4.0 --git-range v1.4.0..HEAD	根据 Conventional Commits 计算下一个 SemVer 版本：破坏性变更 → 主版本号（0.x 中为次版本号），feat → 次版本号，fix → 修订号；可选预发布标签
semver_check	python3 scripts/semver_check.py --check 1.2.3-beta.1	验证严格的 SemVer 2.0.0、比较两个版本，或对版本列表排序
changelog_check	`python3 scripts/changelog_check.py CHANGELOG.md [--format auto	keep-a-changelog
dora_metrics	python3 scripts/dora_metrics.py --events events.json	根据部署和提交事件数据计算全部五项 DORA 指标
release_plan_scaffold	python3 scripts/release_plan_scaffold.py --version 2.0.0 --owner alice --output plan.md	根据标志或 Git 范围中的信息填充占位符，生成发布计划文档框架

触发条件

当任务涉及以下内容时，加载此技能：

• 发布规划 — 设计发布计划、时间线、里程碑或推出策略
• 流水线设计 — 架构设计或评审 CD 流水线、晋级阶段或绿灯后推送
• 版本递增 — 计算下一个版本、验证 SemVer、对 Conventional Commits 进行分类
• 变更日志 — 编写或验证变更日志
• 就绪情况评审 — 做出是否发布的决策、评审候选版本、制定就绪检查清单
• 回滚规划 — 编写或演练回滚操作手册和恢复计划
• 渐进式交付 — 金丝雀发布、分环发布、按百分比逐步推出、流量镜像
• 功能标志 — 标志推出、生命周期管理和清理
• 发布列车 — 日历发布、分支切分、稳定窗口
• DORA 指标 — 定义、计算或报告五项 DORA 指标
• 合规证据 — SOC 2 / SOX / PCI 变更记录、审计跟踪、职责分离
• 制品与供应链 — SBOM、来源证明、签名、注册表卫生
• 紧急发布 — 热修复、紧急授权变更、加速发布流程
• 多团队协调 — 跨团队发布日历和集成稳定工作

何时不应使用

应转到指定的同级技能：

• backend-engineering / frontend-engineering — 实现应用功能。发布工程设计交付代码的流水线；它本身不实现代码。
• systematic-debugging — 分析生产事故的根本原因、定位故障、复现 Bug。发布工程规划恢复方案；调试则负责查找原因。
• site-reliability-engineering — 值班运维、SLO / 错误预算管理、容量规划和日常事故响应。
• secure-software-engineering — 安全实现和威胁建模。发布工程使用安全控制措施（SBOM、签名、依赖项扫描），但不负责设计这些措施。
• platform-engineering — 构建内部开发者平台：CI 基础设施、GitOps 控制器、自助服务工具和黄金路径。
• data-engineering — 数据流水线运维、架构迁移工程和数据质量监控。
• spec-driven-development — 编写规范，并运行 SDD 流水线门禁和判定。
• api-design-and-evolution — API 契约设计和版本管理策略。发布工程会递增制品版本；它不负责制定 API 演进规则。
• verification-methodology — 收集证据，并依据明确的通过 / 失败标准作出判定。

停止和退出条件

• **发布计划完成条件：**计划中列明版本、目标日期、里程碑和分支切出安排、负责人（RACI）、范围项、风险及缓解措施、发布方案、回滚预案、沟通计划和签署批准。
• **就绪检查清单完成条件：**每个维度（功能、非功能、运维、治理）中的每项内容都有负责人和证据，并且已记录是否发布的决定。
• **回滚操作手册完成条件：**触发阈值、影响评估、决策标准、各层回滚步骤、验证 SLI、回滚顺序、沟通安排和演练记录均已就绪。
• **版本递增完成条件：**根据实际提交历史（或明确指定的文件）计算下一个版本，依据严格的 SemVer 进行验证，并说明递增规则为何符合 Conventional Commits 类型。
• **合规记录完成条件：**变更链路（工单 → PR 审查 → CI → 批准 → 部署日志 → 验证）完整、经过抽样检查，并根据策略留存，同时遵守职责分离要求。
• **有界升级：**连续三次诊断均未收敛后停止，并报告目前收集到的证据。