《持续交付》（四）部署发布与基础架构管理

引言

本文是《持续交付》一书学习总结的第四篇。主要内容涉及部署发布和基础架构管理的实践。

部署和发布（一）

这次我们来看看软件持续交付的最后一个步骤：部署和发布。

在项目开始的时候，我们就要想好软件最终发布时要面临的问题，以此制定发布计划和策略。要考虑的问题包括但不限于：

1. 确定部署需要的技术。比如基于Azure平台的应用，部署时就需要微软的Powershell脚本来实现自动化。
2. 如何实现部署流水线。
3. 监控应用程序的技术和策略。有了这些信息可以帮助我们掌握API等服务的实时状态。
4. 与外界系统的集成。应用程序可能访问第三方的外部系统，这些在部署时需要考虑得当。
5. 灾难恢复计划。一旦应用程序出现宕机等灾难情况，要有应急的计划。
6. 问题修复和补丁的策略。
7. 软件的升级和更新策略。
8. 如何回退到某个历史版本。
9. 如何对部署的环境进行冒烟测试。

除了上述技术性的关键问题外，软件的发布还需要一些商业上的考虑。比如，定价模式、软件许可（license）策略、版权信息、市场材料、用户手册和销售支持等信息。

在发布阶段，软件的第一次部署很重要。第一次部署要尽早开始，不能等到产品所有的特性都开发结束后再开始部署。一般可以挑选一系列优先级最高的用户需求加以实现，然后就可以开始部署第一个版本了。

第一次部署不一定就是生产环境，可以从一个类似生产环境的环境开始，比如staging和internal production。在部署时要思考，开发环境和生产环境的区别是什么？这个问题要涉及操作系统、软件工具和依赖、环境管理方式等方面。

软件从构建到发布可以建模为一个构件提升（promoting builds）的过程。通俗地讲，在构建阶段生成的build，要经过各个阶段测试的考验，逐渐提升至发布阶段，用于最后的部署，如下图。从中可以看到，每个菱形的区域代表一个质量门（quality gate），每一道质量门需要特定的人员（如QA）来批准通过。除了build，配置也需要有提升过程。如果配置不能跟随build提升，那么最后部署的环境可能就会缺少配置，导致部署失败。我们可以通过冒烟测试来检查配置是否正确。另外，对于微服务系统，每个服务或组件都要同时提升，尤其是不同组件有依赖关系时。