在ci/cd中加入手动审批不是倒退，而是为生产部署、主干合并、破坏性操作等高风险环节设置可控、可追溯的“安全阀”，需配置环境门禁、提供充分上下文并确保审计闭环。
在CI/CD自动化部署中加入手动确认审批，不是倒退，而是为关键环节加一道可控、可追溯、符合合规要求的“安全阀”。它不打断自动化节奏，而是把发布决策权保留在人手上——尤其适用于生产环境、金融类API、数据敏感服务等场景。
明确审批触发点与适用环境
审批不应处处设卡，而应聚焦高风险动作。常见且合理的触发位置包括：
- 生产环境（production）部署前：这是最普遍也最必要的审批点，确保每次上线都经过人工复核
- 主干分支（main/master）合并后自动触发部署时：防止误推代码直接上生产
- 涉及数据库迁移、配置变更、密钥更新等破坏性操作前：这类变更无法简单回滚，需额外确认
- 满足特定条件才激活审批：例如仅当测试覆盖率≥85%、SonarQube无严重漏洞、或PR由非核心成员提交时才弹出审批
主流平台的手动审批配置方式
不同CI/CD平台实现逻辑相似，但语法和界面操作有差异。关键是利用其“环境保护”或“阶段门禁”能力：
-
GitHub Actions：在job中设置
environment: production，并在仓库 Settings → Environments → production 中启用“Require approval for deployments”，指定审批人或团队 -
GitLab CI：在
.gitlab-ci.yml的deploy job中添加when: manual，并配合environment: production和 protected environment 设置审批规则 -
Drone CI：用
when: event: promote实现UI端一键Promote；或集成drone-approval插件，支持多角色审批、自定义消息、超时自动拒绝 -
Jenkins Pipeline：使用
input指令，如input "Deploy to prod?";，可限定超时时间、审批人权限组，并记录操作日志
让审批信息足够支撑判断
审批者点“Approve”前，需要看到足够上下文，否则审批就流于形式。建议在审批界面上至少展示：
- 本次部署变更摘要：修改了哪些文件、新增/删除了哪些API端点（可通过git diff生成简报）
- 质量门禁结果：单元测试通过率、E2E测试状态、安全扫描（Trivy/Sonar）是否无高危问题
- 构建产物标识：Docker镜像tag、commit SHA、打包时间，避免部署错版本
- 影响范围提示：例如“本次更新将重启用户认证服务，预计影响时长≤30秒”
审批后的闭环与审计
审批不是终点，而是部署链路中的一个节点。后续动作要清晰、可查：
- 审批通过后，自动触发部署任务，不可再人工干预执行过程
- 审批拒绝或超时，应自动标记流水线失败，并通知发起人
- 所有审批操作（谁、何时、批准/拒绝、附带评论）必须写入审计日志，支持导出与合规审查
- 可选增强：审批通过后发送Slack/邮件通知相关方，包含部署链接与回滚指引
