依据证据作出发布决定

准确说明决定

绿色流水线提供的是一组检查的证据，不能完整说明发布决定。负责人需要知道什么会变、在哪里变，以及仍有哪些后果。

对于虚构客户导出功能，明确已接受提交及其产出的制品。写出目标环境，关联相关测试、审查和获批例外。也要纳入随应用一起发生的数据或基础设施变更。

NIST 的 SSDF 提供安全开发实践；SLSA 来源证明帮助说明制品如何产生。二者都不能免除判断这次发布是否适合该服务的责任。参见 NIST SSDF和 SLSA 来源证明。

区分三个事件

合并将源代码修改纳入分支。部署将制品放入环境。功能开放让用户能够使用相关行为。这些事件可以同时发生，但不一定是同一事件。

服务可以先部署未启用的功能，再向用户开放。数据库迁移可能在可见功能出现前就影响生产。应定义实际顺序，不要假设 PR 合并就能说明所有后果。

对于导出功能，功能开关可能限制最初开放的范围，但不会自动保护新端点，也不会撤销数据模式迁移。应在后果实际发生的位置验证控制措施。

审查简明证据记录

使用其他负责人能够检查的记录：

• 目的和受影响用户。
• 提交和制品身份。
• 相关行为、安全和兼容性检查。
• 目标环境和执行身份。
• 剩余例外、负责人和到期条件。
• 监控、恢复方法和响应负责人。

保持陈述具体。“测试通过”不如指向发布提交结果的链接，并附清楚的覆盖范围说明。“可以回滚”不如经过测试、且明确限制的流程。

决定如何停止

执行前定义发布条件。对于虚构导出功能，如果跨组织访问成功、制品与已接受摘要值不符，或无法恢复，就停止发布。这些是示例条件，不是通用清单。

部署后，检查对用户重要的信号。将错误行为和响应时间与服务已接受的目标比较。进程健康，不能证明用户工作流正常。

如果不满足条件，就采用约定的响应方式。可以关闭功能开放、回滚兼容代码，或恢复数据。选择能够处理故障、同时不会造成更大故障的操作。

发布后保留决定记录

记录实际部署的制品和结果。如果执行与计划不同，应明确显示差异。将事件和意外工作反馈到下一次发布设计。

自动化交付系统应让这些记录更易检查，而不是要求审查者从散落的聊天、日志和截图中重建发布过程。清楚的证据，让团队可以自动执行常规工作，同时保留明确的决策责任。