Back to Details

release-pipeline-architect

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Release Pipeline Architect

发布流水线架构设计

Design release pipelines that move one immutable artifact through test, staging, and production with clear gates, rollout strategy, and rollback procedure.
Scope: Release orchestration after code is ready. NOT for infrastructure provisioning (infrastructure-coder), generic CI job optimization (devops-engineer), or release-note writing (changelog-writer).
设计发布流水线，使单个不可变artifact在测试、预发布和生产环境间流转，具备明确的准入gate、发布策略与回滚流程。
适用范围： 代码就绪后的发布编排工作。不适用于基础设施配置（infrastructure-coder）、通用CI任务优化（devops-engineer）或发布说明撰写（changelog-writer）。

Canonical Vocabulary

标准术语表

TermDefinition
release candidateA versioned build proposed for promotion
artifactThe immutable build output promoted across environments
promotionMoving the same artifact to the next environment
gateA manual or automated approval checkpoint
provenanceEvidence tying an artifact to source commit, build, and checks
rolloutThe production exposure strategy: all-at-once, canary, or phased
rollback pointThe last known-good release that can be restored safely
freeze windowA period where changes are limited to release-critical work
hotfix laneA minimal path for urgent production repairs
TermDefinition
release candidate拟用于晋升的带版本号构建产物
artifact在各环境间晋升的不可变构建输出物
promotion将同一artifact移至下一个环境
gate手动或自动的准入审批检查点
provenance将artifact与源码提交、构建过程及检查结果关联的证据
rollout生产环境发布策略：全量发布、金丝雀发布或分阶段发布
rollback point可安全恢复的最后一个已知正常版本
freeze window仅允许发布关键变更的时间段
hotfix lane用于紧急生产修复的极简流程通道

Dispatch

调度模式

$ARGUMENTSMode
design <requirements>
Design a release pipeline and operating model
review <pipeline or runbook>
Audit an existing release flow
cutover <release>
Plan the release-day sequence and handoffs
hotfix <incident>
Design an emergency release lane
checklist <release type>
Produce a release readiness checklist
Natural language about release workflowsAuto-detect the closest mode
EmptyShow the mode menu with examples
$ARGUMENTSMode
design <requirements>
设计发布流水线及运营模型
review <pipeline or runbook>
审核现有发布流程
cutover <release>
规划发布日的流程序列与交接环节
hotfix <incident>
设计紧急发布通道
checklist <release type>
生成发布就绪检查清单
Natural language about release workflows自动识别最匹配的模式
Empty显示模式菜单及示例

Mode Menu

模式菜单

#ModeExample
1Design
design weekly SaaS release with staging and canary prod
2Review
review .github/workflows/release.yml
3Cutover
cutover v2.8.0
4Hotfix
hotfix rollback path for broken payments deploy
5Checklist
checklist mobile app store release
#ModeExample
1设计
design weekly SaaS release with staging and canary prod
2审核
review .github/workflows/release.yml
3发布切换
cutover v2.8.0
4热修复
hotfix rollback path for broken payments deploy
5检查清单
checklist mobile app store release

When to Use

适用场景

  • Creating or redesigning a release workflow
  • Introducing staging, promotion, canary, or rollback controls
  • Formalizing release-day roles, approvals, or freeze windows
  • Building a hotfix process that bypasses non-essential steps safely
  • Reviewing a pipeline that rebuilds artifacts per environment or lacks rollback
  • 创建或重新设计发布工作流
  • 引入预发布、制品晋升、金丝雀发布或回滚控制机制
  • 规范化发布日的角色、审批流程或变更冻结窗口
  • 构建可安全跳过非必要步骤的热修复流程
  • 审核存在跨环境重新构建artifact或缺乏回滚机制的流水线

Classification Gate

分类准入规则

  • If the task is generic CI speed, cache, or workflow tuning, use devops-engineer.
  • If the task is infrastructure provisioning, environment creation, or deployment platform wiring, use infrastructure-coder.
  • If the task is active production incident command, containment, or communications, use incident-response-engineer.
  • If the task is app-level debugging after a deploy without release-process redesign, use investigate or the domain-specific debugging skill.
  • 如果任务是通用CI速度优化、缓存配置或工作流调优，请使用devops-engineer。
  • 如果任务是基础设施配置、环境创建或部署平台搭建，请使用infrastructure-coder。
  • 如果任务是生产事件的指挥、遏制或沟通，请使用incident-response-engineer。
  • 如果任务是部署后的应用级调试且不涉及发布流程重构，请使用investigate或领域特定的调试技能。

Instructions

操作指南

Mode: Design

模式：设计

  1. Gather release constraints: deployment targets, release frequency, downtime tolerance, compliance gates, rollback expectations, and who approves production.
  2. Identify the artifact boundary. Choose the exact build output that must remain immutable across all environments.
  3. Define the release stages in order: build, verify, package, sign, stage, promote, rollout, verify, and archive evidence.
  4. Specify each gate with entry criteria, approver, timeout, and rollback trigger.
  5. Choose a rollout pattern based on blast radius, rollback speed, state-coupling, and operator load. Read 
    references/rollout-decision-matrix.md
    when the rollout shape is not obvious.
  6. Produce a release design that includes versioning scheme, provenance requirements, environment promotion rules, rollback point handling, and approval evidence requirements from 
    references/provenance-evidence-checklist.md
    .
  1. 收集发布约束条件：部署目标、发布频率、停机容忍度、合规准入gate、回滚预期以及生产环境审批人。
  2. 明确artifact边界：确定在所有环境中必须保持不可变的具体构建输出物。
  3. 按顺序定义发布阶段：构建、验证、打包、签名、预发布、晋升、发布、验证及归档证据。
  4. 指定每个gate的准入条件、审批人、超时时间及回滚触发条件。
  5. 根据影响范围、回滚速度、状态耦合度及运维负载选择发布模式。若发布模式不明确，请参考
    references/rollout-decision-matrix.md
    。
  6. 生成发布设计方案，包含版本控制方案、provenance要求、环境晋升规则、回滚点处理方式，以及来自
    references/provenance-evidence-checklist.md
    的审批证据要求。

Mode: Review

模式：审核

  1. Read the workflow, deployment runbook, or release checklist.
  2. Trace how a release candidate is created and whether the same artifact is promoted end-to-end.
  3. Check for missing controls: rebuilds between environments, no approval gates, unclear rollback owner, weak provenance, or no post-release verification. Use 
    references/failure-modes.md
    and 
    references/provenance-evidence-checklist.md
    as the baseline review surface.
  4. Classify findings as critical, warning, or info.
  5. Recommend the smallest set of structural changes that makes the release safer without slowing routine delivery unnecessarily.
  1. 阅读工作流、部署手册或发布检查清单。
  2. 追踪release candidate的创建过程，以及同一artifact是否全程流转晋升。
  3. 检查缺失的控制机制：跨环境重新构建、无审批gate、回滚责任人不明确、provenance薄弱或无发布后验证。以
    references/failure-modes.md
    和
    references/provenance-evidence-checklist.md
    作为审核基准。
  4. 将问题分类为严重、警告或信息级别。
  5. 推荐最小化的结构性变更，在不影响常规交付速度的前提下提升发布安全性。

Mode: Cutover

模式：发布切换

  1. Build a release timeline with explicit owners: release lead, approver, operator, observer, and communications owner.
  2. Sequence the cutover into preflight, freeze confirmation, promotion, rollout, smoke verification, and customer-impact confirmation. Use 
    references/runbook-templates.md
    when producing the final operator-facing runbook.
  3. Define the exact rollback point before rollout starts.
  4. Specify success signals, abort signals, and the maximum decision latency at each stage.
  5. Produce a concise release-day runbook the team can execute without reinterpretation.
  1. 构建明确责任人的发布时间线：发布负责人、审批人、运维人员、观察员及沟通负责人。
  2. 将发布切换流程分为预检、冻结确认、晋升、发布、冒烟验证及客户影响确认环节。生成面向运维人员的最终手册时，请参考
    references/runbook-templates.md
    。
  3. 在发布开始前明确具体的回滚点。
  4. 指定每个阶段的成功信号、终止信号及最大决策延迟时间。
  5. 生成简洁的发布日手册，确保团队无需额外解读即可执行。

Mode: Hotfix

模式：热修复

  1. Narrow scope to the smallest repair that restores service.
  2. Define a hotfix lane that keeps artifact provenance, essential tests, and one production approval.
  3. Exclude non-essential checks only with justification and record what was skipped.
  4. Require immediate post-deploy verification and a follow-up action to restore normal release hygiene. Use 
    references/runbook-templates.md
    and 
    references/provenance-evidence-checklist.md
    so the hotfix lane stays auditable.
  1. 将范围缩小至恢复服务所需的最小修复内容。
  2. 定义保留artifact provenance、必要测试及单次生产审批的热修复通道。
  3. 仅在有合理依据的情况下跳过非必要检查，并记录跳过的内容。
  4. 要求部署后立即进行验证，并制定后续行动以恢复常规发布规范。生成内容时请参考
    references/runbook-templates.md
    和
    references/provenance-evidence-checklist.md
    ，确保热修复通道可审计。

Mode: Checklist

模式：检查清单

  1. Tailor the checklist to the release type: routine, major, infra-coupled, or hotfix.
  2. Group items by preparation, promotion, rollout, validation, and rollback readiness.
  3. Keep each item binary and observable. Use 
    references/runbook-templates.md
    and 
    references/provenance-evidence-checklist.md
    to keep checklist items evidence-backed.
  1. 根据发布类型调整检查清单：常规发布、重大发布、基础设施关联发布或热修复。
  2. 按准备、晋升、发布、验证及回滚就绪分组整理清单项。
  3. 确保每个清单项为二元可观测项。生成内容时请参考
    references/runbook-templates.md
    和
    references/provenance-evidence-checklist.md
    ，确保清单项具备证据支撑。

Output Requirements

输出要求

  • Include a stage-by-stage release flow.
  • Name the artifact, its provenance fields, and the rollback point.
  • State who approves production and what evidence they must see.
  • For review mode, rank findings by severity.
  • 包含分阶段的发布流程。
  • 明确artifact名称、其provenance字段及回滚点。
  • 说明生产环境审批人及所需查看的证据。
  • 审核模式下，按严重程度对问题进行分级。

Critical Rules

核心规则

  1. Always promote one immutable artifact across environments. Never rebuild for production.
  2. Always define a rollback point before production rollout begins.
  3. Production release plans must include a named approver and explicit abort criteria.
  4. A hotfix lane may skip non-essential steps, but never provenance, essential validation, or rollback preparation.
  5. Release recommendations must optimize for recovery time, not just deployment speed.
  6. If a pipeline mixes release orchestration with infrastructure provisioning, split responsibilities and route infra work to infrastructure-coder.
  1. 始终在各环境间晋升单个不可变artifact，绝不为生产环境重新构建。
  2. 生产发布开始前必须明确回滚点。
  3. 生产发布计划必须包含指定的审批人及明确的终止条件。
  4. 热修复通道可跳过非必要步骤，但绝不能跳过provenance、必要验证或回滚准备工作。
  5. 发布建议必须优先优化恢复时间，而非仅关注部署速度。
  6. 若流水线混合了发布编排与基础设施配置工作，请拆分职责，并将基础设施相关工作交由infrastructure-coder处理。

Scaling Strategy

扩展策略

  • Start with one immutable artifact path, one production approver, and one rollback point before layering on advanced rollout controls.
  • Use the simplest rollout pattern that matches blast radius and recovery needs; escalate from all-at-once to canary, phased, or blue/green only when the decision matrix justifies it.
  • Separate routine release, high-blast-radius release, and hotfix lanes so speed improvements do not weaken safety-critical controls.
  • 从单条不可变artifact流程、单个生产审批人及单个回滚点开始，再逐步添加高级发布控制机制。
  • 使用最符合影响范围与恢复需求的最简发布模式；仅当决策矩阵支持时，才从全量发布升级为金丝雀发布、分阶段发布或蓝绿发布。
  • 将常规发布、高影响范围发布与热修复通道分离，确保速度优化不会削弱安全关键控制。

Reference File Index

参考文件索引

FileRead When
references/rollout-decision-matrix.md
Choosing between all-at-once, canary, phased, and blue/green rollout patterns
references/provenance-evidence-checklist.md
Defining artifact identity, approval evidence, release records, and post-release proof
references/failure-modes.md
Reviewing an existing pipeline for structural release risks and rollback gaps
references/runbook-templates.md
Producing cutover runbooks, hotfix lanes, and binary release-readiness checklists
FileRead When
references/rollout-decision-matrix.md
在全量发布、金丝雀发布、分阶段发布与蓝绿发布模式间做选择时
references/provenance-evidence-checklist.md
定义artifact标识、审批证据、发布记录及发布后证明时
references/failure-modes.md
审核现有流水线的结构性发布风险与回滚漏洞时
references/runbook-templates.md
生成发布切换手册、热修复通道及二元发布就绪检查清单时

Scope Boundaries

范围边界

IS for: release trains, approvals, environment promotion, rollout strategy, rollback design, cutover sequencing.
NOT for: generic CI optimization, infrastructure provisioning, app-level debugging, or changelog copy.
适用场景： 发布列车、审批流程、环境晋升、发布策略、回滚设计、发布切换序列。
不适用场景： 通用CI优化、基础设施配置、应用级调试或变更日志撰写。