deployment-automation

部署自动化

当任务是在系统已具备构建能力后，安全地执行发布时，使用此技能。

deployment-automation 是此仓库的发布执行核心，适用于：

• 预览发布和可分享的审查环境
• staging → production 提升及签核关卡
• 发布策略选择：替换、滚动、蓝绿、金丝雀、渐进式
• 部署后验证和停止条件
• 回滚响应和问题发布遏制
• 围绕现有部署路径完善发布加固方案

在确定方案前，请阅读以下支持文档：

• references/deployment-modes-and-boundaries.md
• references/release-packet-templates.md
• references/strategy-selection-and-stop-conditions.md
• references/rollout-and-rollback-checklist.md
• references/platform-routing-notes.md

何时使用此技能

• 已有预览或分支部署，但团队尚未就合并前需要验证什么达成一致。
• 发布在技术上已可运行，但 staging/prod 提升仍依赖口口相传的经验。
• 主要决策涉及发布策略、发布关卡、验证深度或回滚准备情况。
• 部署失败，接下来的工作是遏制影响、回滚和安全恢复，而不是大范围重设计平台。
• 团队在使用特定平台的运维技能前，需要一份与供应商无关的发布方案。
• 需要通过预检、签核逻辑和明确的停止条件来加固现有部署路径。

何时不使用此技能

• 主要任务是安装 Docker、kubectl、云端 CLI、认证引导配置，或让机器具备运行条件 → system-environment-setup
• 主要任务是仪表板、告警、跟踪或长期遥测架构 → monitoring-observability
• 主要任务涉及 Vercel 专属的关联、域名、别名、环境变量或 claim URL → vercel-deploy
• 系统尚不能构建、打包或运行测试 → 先修复构建/设置问题，再处理部署自动化
• 主要任务涉及密钥轮换、IAM 策略、签名或合规架构 → 转交相关安全技能

说明

第 1 步：锁定发布配置

在建议步骤前，先规范化请求。

release_profile:
  mode: preview-release | environment-promotion | container-paas-rollout | kubernetes-rollout | rollback-response | release-hardening
  runtime_shape: static-frontend | web-app | api-service | worker-job | multi-service | unknown
  artifact_shape: platform-build | image | build-output | package | unknown
  target_environment: preview | staging | production | mixed | unknown
  promotion_model: same-artifact-promotion | rebuild-per-env | direct-deploy | unknown
  rollout_strategy: replace | rolling | blue-green | canary | progressive | feature-flag-assisted | unknown
  stateful_risk: low | medium | high | unknown
  verification_depth: health-only | smoke-tests | release-checklist | automated-analysis | unknown

每次运行只选择一个主要 mode：

• preview-release — 合并或提升前可分享的验证
• environment-promotion — staging → production 或带关卡的多环境提升
• container-paas-rollout — 托管应用/容器平台的发布规划
• kubernetes-rollout — 发布控制器行为、停止条件和回滚路径
• rollback-response — 问题部署的遏制与恢复
• release-hardening — 为现有流程补充缺失的预检、审批或验证

第 2 步：收集最少且真实的证据

不要凭感觉编造发布流程。只收集必要的真实信息：

1. 实际要发布的制品是什么？
2. 当前涉及哪个环境？
3. 同一制品会在不同环境间提升，还是每个环境都会重新构建？
4. 当前使用的部署命令、供应商操作或控制器是什么？
5. 已有哪些健康检查、冒烟测试或签核信号？
6. 实际的回滚方法是什么？
7. 是否有会导致回滚方式不对称的架构/数据变更？

如果有任何答案未知，请明确说明，并采用范围最小的安全解释。

第 3 步：尽早明确边界

生成发布方案前，先按以下规则分流：

如果请求实际涉及……	转交至
Docker/kubectl/云 CLI 安装、身份验证初始化、机器就绪状态	system-environment-setup
仪表板、告警、追踪、日志流水线、SLO 监控	monitoring-observability
Vercel 项目关联、别名、域名、环境变量、Vercel 部署机制	vercel-deploy
密钥轮换、IAM 范围、签名、证明、合规证据	安全技能
发布方式选择、晋级门槛、验证、回滚方案	deployment-automation

第 4 步：加载合适的支持方案，而不是扩充入口

完成分类后，使用相应的参考方案：

• preview-release → references/release-packet-templates.md#preview-release-packet
• environment-promotion → references/release-packet-templates.md#environment-promotion-packet
• container-paas-rollout → references/release-packet-templates.md#containerpaas-rollout-packet
• kubernetes-rollout → references/release-packet-templates.md#kubernetes-rollout-packet
• rollback-response → references/release-packet-templates.md#rollback-response-packet
• release-hardening → references/release-packet-templates.md#release-hardening-packet

选择替换式、滚动式、蓝绿、金丝雀或渐进式方案时，使用 references/strategy-selection-and-stop-conditions.md。 定稿前，将 references/rollout-and-rollback-checklist.md 作为最低发布安全检查清单。

第 5 步：遵循发布执行规则

• 区分构建与发布。 构建通过并不能证明发布安全。
• 区分部署与流量开放。 流量切换、晋级门槛和功能标志可能比初始部署命令更重要。
• 区分应用回滚与数据回滚。 切勿暗示两者相同。
• 优先选择与团队验证成熟度相匹配的最小发布策略。
• 在可复现性重要时，优先晋级同一构建产物。 如果系统会为每个环境重新构建，应明确指出风险。
• 必须进行验证。 健康检查加一项核心流程，是最低可接受的完成标准。
• 停止条件优先于乐观预期。 明确指出哪些情况应阻止晋级或触发回滚。

第 6 步：提供发布方案，而不是 DevOps 说教

输出应始终包含：

# Release Packet
- Mode:
- Runtime / provider:
- Artifact:
- Environment(s):
- Promotion model:
- Rollout strategy:

## Preconditions
- Existing deploy path:
- Required auth/config:
- Known blockers / migrations:

## Steps
1. ...
2. ...
3. ...

## Verification
- Health checks:
- Smoke checks:
- Human/automatic sign-off:
- Stop conditions:

## Rollback / recovery
- Immediate rollback path:
- What rollback does not undo:

## Handoffs
- Adjacent skills or provider-specific follow-up:

第 7 步：优先加固，而不是不断增加封装层

如果请求听起来像是“部署一团糟”，应优先：

1. 对发布模式进行分类，
2. 明确当前的事实来源，
3. 增加预检、验证和回滚结构，
4. 将平台细节转交给相应的相邻技能。

不要通过另造一个通用部署封装、重新讲解整个 Kubernetes，或将 CI 编写工作纳入本技能来回应。

输出格式

返回：

1. 选定的发布模式，
2. 收集到的证据和未知事项，
3. 发布策略及理由，
4. 验证计划，
5. 回滚或恢复计划，
6. 转交事项或剩余风险。

示例

示例 1：对预览部署感到困惑

输入：“每个 PR 都会生成一个预览 URL，但评审者总是批准有缺陷的流程。合并前，部署流程实际上应该要求什么？”

输出形式：将其归类为 preview-release，明确预览能证明什么，列出冒烟测试，并区分预览验证与后续的预发布/生产晋级。

示例 2：从预发布环境晋级到生产环境

输入：“我们会自动部署到预发布环境，但晋级到生产环境仍然要通过 Slack 手动操作。请给我们一份最安全的发布方案。”

输出形式：将其归类为 environment-promotion，明确构建产物和门槛，要求晋级后的检查，并说明回滚方案及架构变更注意事项。

示例 3：生产部署失败

输入：“最新版本在生产环境中超时，而且还包含了一项迁移。我们需要最稳妥的回滚方案。”

输出格式：归类为 rollback-response，控制影响范围，将应用回滚与迁移风险分开，并定义恢复后的验证步骤。

最佳实践

1. 入口内容应聚焦于发布决策，而非平台百科。
2. 提出建议前，先明确实际产物、环境和回滚路径。
3. 优先提供简短的发布方案，便于运维人员在压力下执行。
4. 尽早将特定于提供商及相关领域的问题转交出去。
5. 将验证步骤和停止条件视为必需输出，而非可有可无的润色。

参考资料

• Kubernetes 部署
• Argo Rollouts
• Vercel 部署