持续交付发布可靠软件的系统方法（部署流水线）第十章：应用程序的部
引言
发布到生产环境和部署到测试环境的差异应该被封装在一组配置文件中，遵循一样的部署过程。启动自动部署系统，将要部署的软件版本与环境名称告诉它，点击开始，后缀部署与发布使用相同的流程。
我们需要有一个列表，其中包含能够部署到每个环境的所有构建，并且只要通过点击就可以选择一个软件版本向某个环境进行自动部署。同时这种方式是对环境修改的唯一途径（包括对操作系统和第三方软件配置的修改）。
创建发布策略（文档）
- 每个环境的部署由发布由谁负责
- 创建一个资产和配置管理策略
- 部署时所用的技术的描述。运维团队与开发团队应对其达成共识
- 实现部署流水线的计划
- 枚举所有的环境，包括用于验收测试、容量测试、集成测试、用户验收测试的环境，以及每个构建在这些环境中的移动过程
- 描述在测试和生产环境中部署时应该遵循的流程，比如一个变更申请，及申请授权等
- 对应用程序的监控需求，包括用于通知运维团队关于应用程序相关状态的API和服务
- 讨论部署时和运行时的配置方法如何管理，以及它们与自动化部署流程是如何关联在一起的
- 描述应用程序如何与所有外部系统集成
- 如何记录日志详情，以便运维人员能够确定应用程序的状态，识别出错原因
- 制定灾难恢复计划，以便在灾难发生后，恢复应用程序的状态
- 对软件的服务级别达成一致
- 生产环境的数量大小 及容量计划：应用程序会创建多少数据，需要多少个日志文件或数据库，需要多少带宽或磁盘空间，用户对响应延迟的容忍度是什么？
- 制定一个归档策略，以便不必为了审计或技术支持而保留生产数据
- 如何对生产环境进行首次部署
- 如何修复生产环境中出现的缺陷，并为其打补丁
- 如何升级生产环境中的应用程序以及迁移数据
- 如何做应用程序生产服务与技术支持
随着项目的进行，这个策略文档也会改变
应用程序的部署与晋级
每次部署时都使用同样的方法，使用相同的流程向每个环境部署，包括生产环境。在首次向测试环境部署时就应该使用自动化部署。
首次部署
在第一个迭代里，选择一至两个具有高优先级但非常简单的用户故事或需求，让部署流水线的前几个阶段可以运行，且能够部署并展示一些成果。把它看作实现部署流水线的“抽水泵”
这个启动迭代结束后，应该已经完成了以下内容：
- 部署流水线线的提交阶段
- 一个用于部署的类生产环境
- 通过一个自动化过程获取在提交阶段中生成的二进制包，并将其部署到这个类生产环境（UAT）中
- 一个简单的冒烟测试，用于验证本次部署的正确性
对发布过程进行建模并让构建晋级
在构建中重点注意以下内容
- 为了达到发布质量，一个构建版本要通过哪些测试阶段
- 每个阶段需要设置怎样的晋级门槛或者需要怎样的签字许可
- 对每个晋级门槛来说，谁有权批准让该构建通过该阶段
测试与发布流程
配置的晋级
除了二进制需要晋级，环境与应用程序的配置信息也需要晋级。但是并不是所有的配置都需要晋级，这就需要对配置信息进行晋级管理。
- 用冒烟测试来验证配置信息的正确性。
- 对于中间件的配置，利用像Nagios这样工具来监控这些设置。
- 写一些对基础设置的测试，用于检查关键设置，并将其返回给监控软件。
联合环境
SIT环境中更多的工作是部署每个应用程序的新版本，直到所有应用程序可以互相联通。
部署到试运行环境
项目开始时就需要计划以下事情：
- 确保生产环境、容量测试环境和试运行环境已准备好
- 准备好一个自动化过程，对环境进行配置，包括网络配置、外部服务和基础设置
- 确保部署流程是经过充分冒烟测试的
- 度量应用程序的“预热”时长。如果应用程序使用了缓存，这一点就尤其重要，将它也纳入到部署计划中
- 与外部系统进行测试集成
- 如果可能，发布之前就把应用程序放在生产环境上部署。蓝绿部署
- 如果可能，把应用程序发布给所有人之前，将它发布给一小部分用户群。金丝雀发布
- 将每次已通过验收测试的变更版本部署在试运行环境中
部署回滚和零停机发布
制定回滚计划时，需要遵循两个原则：
- 发布前，确保生产系统的状态（数据库和保存在文件系统中的状态）已备份
- 每次发布之前都练习一下回滚计划，包括从备份中恢复或把数据库备份迁移回来
通过重新部署历史版本进行回滚
优点：可预知时间内恢复，且风险较低；部署操作经过运行，而回滚频率低，所以回滚脚本更不稳定
缺点：部署需要时间，业务有中断；覆盖部署，难以查找问题原因；新版本运行时产生的数据丢失。
零停机部署
将用户从一个版本几乎瞬间转移到另一个版本，如果出问题，可以瞬间将用户转到碑的版本上。不同版本应用独立部署。
蓝绿部署
保留两个相同的生产环境版本，“蓝环境”、“绿环境”。
将新版本部署在“蓝环境”下，在蓝环境下测试完成后，将路由配置到蓝环境。如果出现问题，把路由器切回到绿环境上即可，此时蓝环境用于查找问题。
蓝绿部署要小心管理数据库。解决办法如下：
在切换之前暂时将应用程序变成只读状态一小段时间，将绿数据库复制一份，并恢复到蓝数据库中，执行迁移操作，再将用户切换到蓝系统。如果一切正常，再把应用程序切换到读写方式，如果出现问题，只要把它切回绿数据库就可以了。
如果问题出现时，应用程序中已经写入了一些数据到蓝系统，那么切回去之前需要将新记录迁回到绿数据库中
还可以找个办法让应用程序的新版本把数据库事务同时发向新旧两个数据库
如果只有一个生产环境，也可以使用蓝录部署。让应用程序两个副本一起运行在同一个环境中。
金丝雀发布
金丝雀发布：把应用程序的某个新版本部署到生产环境中的部署服务器中，从而快速得到反馈。
- 部署新版本到一部分服务器上，对新版本上做冒烟测试，容量测试。
- 选择一部分用户，把他们引到新版本上
- 还可以部署多个版本，将不同组用户引导到不同版本上
好处：
- 非常容易回滚，只要不把用户引到有问题的版本
- 将用记引致新旧版本，从而作A/B测试
- 可以通过逐渐增加负载，慢慢地把用户引到新版本，检验应用程序是否满足容量需求
紧急修复
牢记：任何情况下，都不能破坏流程。紧急修复版本也需要走构建、部署、测试和发布流程。
让每个紧急修复都走完标准的部署流水线。
紧急修复的另一个做法是回滚到旧的好版本上。
处理生产环境的缺陷时应用考虑以下因素：
- 别加班到深夜来做，应该与别人一起结对做
- 确保有一个已经测试过的紧急修复流程
- 对于应用程序的变更，避免绕过标准的流程，除非在极端情况下
- 确保在试运行环境上对紧急修复版本做过测试
- 有时候回滚比部署新的修复版本更划算
持续部署
使用部署流水线、让部署到生产也自动化。如果某次提交的代码通过了所有的自动化测试，就直接部署到生产环境中。
持续部署可以与金丝雀发布结合，先通过自动过程发布给一小部分用户，如果没有问题，就发布给所有用户。
小贴士
- 真正执行部署操作的人应该参与部署过程的创建
- 记录部署活动
- 不要删除旧文件，而是移动到别的位置
- 部署是整个团队的责任
- 服务器应用程序不应该有GUI
- 为新部署留预热期
- 快速失败
- 不要直接对生产环境进行修改
