第二章 过程改进，没有灵丹妙药

    很无助

    “等会儿！我们不能把未经测试的代码扔给客户。他们会勃然大怒的！同样也不要让我们公布未正式公开及未认证的合作方代码。你疯了吗？”闭嘴，成熟些吧。生产第一。现在的问题是配置生产环境对未公开代码进行测试与认证。

    这种解决方案称为“持续部署”（continuous deployment）。这个概念很简单：将多个创建（build）部署到生产环境中去，使用自定义的路由定向。就像面向规范服务（regulating service）（而不是源码）的源码控制系统。这种系统没有构建进Azure及其他云系统是不可想象的。

    实现持续部署有很多种方法，这些方法与部署系统及自定义路由的灵活性有本质的不同。但是，持续部署的实现要相对简单。

    最困难的部分是数据处理，必须使其在各种创建间保持有效。然而，如果一项服务被设计成在一项新的创建部署后能执行至少一次回滚，即使这项新创建使用了新数据，那么这项服务在一个持续部署的环境中就能运作良好。

    作者注：你还需要注意多种创建间设置的多样性问题。这有点棘手，但还不算很糟。理想情况下，你的设置不会时常改变。如果新创建依赖于.NET Framework或操作系统的最新版本，那么这些新创建必须放到新配置的机器上——但你没必要对持续部署做什么更改。对于数据及模式的变动，我强烈建议不要配置多种数据库。相反，在数据行、列及表增加时应用模式的变更而不要在数据行、列及表变更或删除时应用模式。如我之前所说，你必须这样做，即使你不采用持续部署。

    当你必须对模式做重大变更时，成熟的做法是做双版本准备：

    第一种版本，创建一个能认识老的及新的模式的版本，并进行对应处理。（这并不是个新鲜的重大功能，它只是具有一种处理两种模式的能力。）

    第二种版本，当第一种版本稳定后，推出一个依赖于新模式的版本。现在，如果还有问题，你就有了一种安全的回滚机制。

    怎样才能办到

    如何在集成测试、合作方测试、压力测试及认证环境中使用持续部署？我们来逐个讲讲。

    集成测试你在生产环境中部署了新的创建，但只是设置你们的工程师团队与创建间的自定义路由来指定路径（默认本来是没有路由的），其他所有人都在等候着你最终的公开版本。这种技术叫做“曝光控制”（exposure control）。那现在你的团队可以在一个有着实际生产数据及实际生产负载（采用未向客户公开的创建）的真实生产环境中测试了。

    作者注：你需要一个功能强大的诊断工具来分析你在生产环境中发现的错误，不管是不是持续部署都该如此。

    合作方测试合作方将他们的新创建部署到生产环境中，并只在他们的工程师团队与他们的创建间设置自定义路由来指定路径。其他人看不到变更。现在合作方可以在没人（包括其竞争者）知道其工作进展的情况下对你的生产服务进行测试，

    压力测试你在生产环境中部署了最新创建并完成测试。一旦通过验证，你通过“曝光控制”逐步提升最新创建的实时路由负载——先是1%，再是3%，然后10%，30%，100%，你在这个过程中监测服务状态。如果你的服务出现错误信号，就记录下数据及路由负载回到前一个版本中（实时回滚）。

    认证合作方在生产环境中部署他们的最新创建并对它们进行测试。一旦这些创建被验证，合作方使用“曝光控制”将认证团队定向到他们的最新创建上。在客户或竞争者看到他们的最新进展前，这个认证团队在生产环境中对他们的创建进行认证。当这些创建通过认证后，合作方可以选择何时将实时路由定向到他们的创建上。

    Beta红利！你部署一个Beta版创建时，一旦它通过验证，你利用“曝光控制”将Beta版用户定向到Beta版创建上。

    改良红利！你另外部署了一个当前创建的改良版。当它通过验证时，你使用“曝光控制”将一半的实时路由负载定向到你当前的创建上，将另一半定向到新的改良版上。你利用在使用模式（usage pattern）中见到过的这种差别提升服务的效率。

    自动回滚红利！在你将所有的实时路由负载定向到新创建上后，你将之前的版本留在原处。将你的健康检测系统与曝光控制系统连接。如果你的健康检测系统提示错误，则曝光控制系统将马上自动重定向路由至你之前的版本——无论白天还是晚上。