发布管理

发布管理是一门规划、安排和控制软件变更如何进入生产环境的学科。它涵盖了版本发布的内容、验证方式、部署方式、后续监控以及出现问题时的回滚方式。其目标是使从构建版本到生产环境的过渡过程变得平顺而非充满变数。

该领域最一致的发现与直觉相悖。大型版本发布给人的感觉更安全，因为它将风险集中到一个精心管理的事件中，但交付性能研究的证据却指向相反的方向：频繁的小版本发布可以降低故障率并加快恢复速度。大型版本发布会捆绑许多变更，因此一旦出现问题，就很难确定原因，而且回滚操作会丢弃所有变更，而不是仅仅丢弃那个出错的变更。

部署自动化是实现高频率部署的基础。手动部署流程缓慢、不一致且容易出错，每次发布的高成本迫使企业批量处理变更，而这恰恰导致了风险更高的大规模发布。通过自动化部署流程，使部署可重复且高效，可以消除企业囤积变更的动机。

将部署与发布分离是改变风险状况最有效的技术。例如，将代码部署到生产环境时，先用一个标志禁用某个功能，然后再单独启用该功能，这意味着技术上的代码交付行为和业务上的功能开放行为不再同步。这样一来，部署中的问题可以在不影响用户的情况下被发现，而且功能可以逐步开放，也可以立即撤回，无需重新部署任何内容。

渐进式测试自然源于这种分离。先向一小部分流量发布，监控错误率和业务指标，然后逐步扩大范围，可以将任何问题的影响范围限制在极少数用户。这种方法比大规模的预发布测试更能有效地发现那些仅在真实生产环境、负载和数据下才会出现的问题。

回滚能力必须经过验证，而不能想当然，很多组织正是在最糟糕的时刻才发现问题所在。一份从未执行过的、记录在案的回滚流程在真正需要时往往会失效，尤其是在涉及数据库迁移且模式变更无法简单撤销的情况下。只有真正实践回滚，并将迁移设计为向后兼容，确保旧版本能够继续运行，才能真正建立起安全保障。

发布后的监控是整个流程的一部分，而非独立于流程之外的环节。部署成功并不意味着发布完成；只有当系统在实际流量下运行正常时，发布才算真正完成。预先定义需要监控的指标、监控时长以及触发回滚的阈值，可以将发布后的监控阶段从模糊的观察转变为一个明确的步骤，并最终做出相应的决策。

版本发布相关的沟通比团队预想的更为重要，尤其是在变更会影响到客户或内部用户（他们需要做好准备）的情况下。支持团队需要在客户询问之前了解变更内容，而未事先通知的界面变更会导致大量的咨询，其影响远超变更本身。向负责解答问题的人员发送一份简明扼要、可靠的通知，成本不高，却能有效避免可预见的干扰。

由于发布实践不仅取决于流程，还取决于底层交付基础设施，因此改进通常需要工程投入，而不是流程变更。在实践中，这一点已在内部得到证实。 产品开发发布后监测依赖于通过以下方式维护的测量数据： 数据分析 这样一来，人们就能观察到业务影响，而不仅仅是技术健康状况；在运行众多服务的组织中，标准通常由多个组织共同拥有。 IT部门 而不是逐队设置。