发布不能是一场赌博。

构建来源、依赖项与访问边界

流水线要处理第三方软件包、构建工具，并且往往拥有影响范围很广的访问权限。我们梳理这条信任链，将对不可信变更的检查与拥有生产权限的步骤区分开来。执行环境需要有限的权限和可追溯的初始状态。访问凭证以受控方式提供，且不得出现在制品或构建日志中。

对于已发布的制品，其源代码版本、依赖项和已完成的检查应当可以追溯。组件清单有助于日后评估已知漏洞，但并不能自动证实这些漏洞是否可被利用。签名和来源证明只有在接收环境同样进行验证时才有意义。因此，我们会共同确定生成、存储和验证的方式，并约定如何处理被禁用的组件或已遭入侵的访问凭证。

数据库架构与应用版本协同交付

在逐步发布的过程中，新旧应用版本可能同时处于运行状态。立即删除的数据库列或更改的消息格式，都可能破坏旧版本。因此，我们会规划兼容的过渡状态：先补充新结构，以受控方式迁移数据，切换调用方，然后才移除不再需要的部分。后台任务和外部消费方也需要一并纳入考虑。

功能开关可以将功能的部署与其启用区分开来。但它们需要明确的责任归属、测试变体和预定的失效日期，否则会持续增加可能状态的数量。每次发布都会记录哪些版本可以协同工作，以及应用是否仍可以被回退。不可逆的数据变更所需要的策略，不同于简单替换可执行制品。

发布信号与开发流程改进

技术上交付成功，并不等于发布成功。上线后，我们会观测选定的核心业务操作、错误率和响应时间。分阶段发布可以限制受影响的用户范围，但这需要合适的架构和有意义的测量点。中止阈值和责任人会在变更之前确定，这样在时间压力下就不必再讨论衡量标准。

为了改进流程，我们会关注评审的等待时间、流水线耗时、频繁的中止情况，以及变更失败后恢复所需的工作量。这些信息用于改进整体流程，而不是对个别开发人员进行排名。如果构建速度很快，但之后的审批还要拖上好几天悬而不决，那么速度的意义就不大。因此，相关措施会与开发、安全和运维团队共同商定优先级，并结合实际瓶颈进行核查。