设计多阶段 CI/CD 部署流水线：审批门禁…

在为新服务设计零停机部署流水线、配置金丝雀/蓝绿发布、搭建多环境晋级流程或排查部署门禁失败时使用。

适用场景

解决思路

1. 明确输入信息：应用类型（语言/运行时、容器化或裸机、单体或微服务）、部署目标（Kubernetes、ECS、VM、serverless 或 PaaS）、环境拓扑（dev/staging/prod 数量、区域布局、隔离要求）、发布要求（可接受停机时间、回滚 SLA、流量切分需求、金丝雀或蓝绿偏好）、门禁约束（审批团队、测试覆盖率阈值、SAST/DAST/SCA 合规扫描）、监控栈（Prometheus、Datadog、CloudWatch 等用于自动晋级决策的指标源）。
2. 产出流水线配置：定义各阶段（stage）、作业依赖关系、并行策略与缓存策略。
3. 产出部署策略：选定发布模式并附上带注释的配置（金丝雀权重、蓝绿切换、滚动发布参数）。
4. 产出健康检查方案：区分浅层与深层就绪探针，编写部署后冒烟测试脚本。
5. 产出质量门禁定义：自动化指标阈值与人工审批工作流。
6. 产出回滚方案：自动回滚触发条件与人工 runbook 步骤。
7. 健康检查在生产中失效时：不要用只返回 200 的浅层 /ping 端点，改用会验证实际依赖（如数据库连通性）的深层就绪检查。
8. 金丝雀发布卡在未晋级到 100% 时：Argo Rollouts 需要有效的 AnalysisTemplate 才能自动晋级；若 Prometheus 查询无数据（如指标名变更），分析会一直处于 inconclusive 状态导致晋级停滞。添加 inconclusiveLimit 让 rollout 快速失败而非无限挂起，例如：spec.metrics[].inconclusiveLimit: 2，并配置 failureCondition: "result[0] > 0.05" 与 prometheus query。
9. staging 部署成功但 production 作业不启动时：检查生产环境防护规则，缺少 reviewer 指派会导致审批门禁无限等待且无通知；在 GitHub Actions 中确认 Settings → Environments → production 的 Required reviewers 已设置为存在的用户或团队。
10. Docker 层缓存每次都被击穿导致构建缓慢时：若 COPY . . 出现在依赖安装之前，任何源码变更都会使依赖层失效；应改为先复制依赖清单再安装依赖，例如 COPY package*.json ./ → RUN npm ci → COPY . . → RUN npm run build。
11. 回滚后数据库迁移仍作用于旧代码时：服务回滚必须同时回滚迁移，否则出现 schema/代码不匹配；至少一个发布周期内迁移必须向后兼容（仅做增量），并将 undo 脚本与迁移一起版本化，例如 migrations/V20240315__add_nullable_column.sql 与 migrations/V20240315__add_nullable_column.undo.sql 成对保存。
12. 在旧代码版本从所有环境完全退役之前，绝不执行破坏性迁移（DROP COLUMN、ALTER NOT NULL）。
13. 需要平台特定流水线配置、多区域晋级工作流或高级 Argo Rollouts 模式时，阅读 references/advanced-strategies.md（含 GitHub Actions、GitLab CI、Azure Pipelines 的扩展 YAML 示例、多区域金丝雀模式与数据库迁移回滚策略）。
14. 当上述导航层信息不足时，阅读 references/details.md 获取详细模式文档与完整示例。

适用边界 · 注意事项

• 需要特定平台实现细节（GitHub Actions、GitLab CI、Azure Pipelines 的具体语法）时，应转用对应技能（github-actions-templates、gitlab-ci-patterns）。
• 涉及 CI/CD 中的密钥管理时，应转用 secrets-management 技能。
• 没有明确部署目标、环境拓扑或监控指标源时，无法设计有效的门禁与晋级策略。