2010年12月1日：“生产第一”
我是这么深爱着微软，我们拥有这么多的优越条件，这个公司拥有着一群充满智慧的人，更拥有富有生命力的产品及独到的视角，但时常还是有人那么无知——微软是一个海纳百川的公司，但这些无知足以让你发狂。
再看我们的服务环境，这里有个我们自己的例子。目前我的团队已将服务环境分成软件开发、签入测试、情景测试、压力测试、跨部门整合、合作者整合、认证及生产等8个不同的环境——我们还计划在明年增建一个产前环境。但是一句给你泼冷水的黑色幽默是：即使拥有所有这些环境，仍然会有大量的毛病及意外只在生产环境中才被发现。
为什么我们会这样挥霍无度？因为我们够资本（这很好但不是很好的借口），还因为还有很多老古董的企业工程师不明白服务的真谛：生产第一。这些工程师妄想万事俱备再行测试并奢望有一个难得的商业软件集成环境，他们仍这样执迷不悟。闭上眼，一起按下Ctrl+Alt+Delete键三次，好好反思：“生产第一，生产第一，生产第一。”
作者注：虽然这是我最近才写的一篇专栏，但其已是我在微软所写专栏中最有影响力并被引用最多的一篇。我已收到多个管理级别部门的电子邮件，在其中详尽讨论了这个想法或直言说：“生产第一。”这让人倍感温馨。
这事怎么就成了
哪些傻瓜创建并维护着这些没用的服务环境？这些人毁了企业级软件开发。
大型商业企业依赖于企业级软件——它们必须运行正常，否则他们不会购买。一旦他们购买了软件，他们就是所有者。企业级软件不是你想改就改的。是的，即使是打个安全补丁。
记住，企业的支票是视软件运行是否顺畅而定的。软件的所有改动都直接给企业商务带来风险。如果软件出问题或运行欠佳或不能保持持久稳定，企业是不会买的。他们会跟你说：“打个补丁？这鬼主意不错。”
微软所有的工程师都明白了这艰深的道理：在代码未经全部测试之前，你是不能发布软件的。企业级软件是不容许“重试”的。
未经在生产环境中检测就发布软件，这是企业级工程师想都不敢想的。如果他们理解了服务的真谛，他们是该幸灾乐祸了。
拜托，你不能认真一点吗
软件服务的真谛是什么？生产第一位。让我们逐个击破这些关于测试与集成环境的神话：
如果签入测试系统在某种环境中通过，那么它们在所有环境中都会通过。好的，这明显是错误的，但这里还有更糟糕的问题。写一些除了在生产环境而在其他地方都会失败的严谨的登录测试系统并不难（像广播测试及数据库镜像测试）。不要自欺欺人了，还是在开发人员登录之前，写一些完整的自动登录系统，使它们在其开发环境中快速运行。
在将代码与合作方整合之前，你需要一个独立的环境测试各种情况。人们相信这一点有两个原因：他们不希望不稳定的代码破坏合作方的代码，以及他们不希望合作方不稳定的代码来妨碍测试。第一个理由很有道理——你需要一个测试环境来做一些验收及压力测试，特别是对一些关键组件。第二个理由就很可笑了——就好像，无论在什么状况下，你的合作伙伴都将确保你的测试环境无恙。他们不会，也不能（以下将详细说明）。
你不想在生产环境中进行压力测试。为什么不？你担心生产过程会出意外？你不想知道为什么吗？这不是真正的目的吗？明白什么东西在可控情况下出问题并在必要时回退，这不很好吗？你还好吧？
你需要在发布之前通过集成环境对跨部门情况进行测试，并提供产前环境对外部合作方进行访问。假设在进入生产环境前，跨部门运作良好；再假设，发布前外部合作方在另一个环境中已完工。你现在敢保证质量吗？
不，都不敢。在生产阶段诸事难料，那时有更多的机器，不一样的负载条件，不同的路由及负载平衡，不同的配置，不同的设置，不同的数据及认证，不同的操作系统及补丁，不同的网路及不同的硬件。你会发现一些集成问题，但并不能说明这样庞大的开销是值得的。
作者注：一个虚拟的云环境，就像Azure，会有这样的问题吗？不，它仅仅解决了不同的操作系统设置与补丁以及不同硬件问题。它对于其他问题来说也小有益处，但生产就是生产，不可替代。
你需要一个受保护的认证环境。为什么你事先要验证一下产品？因为你想确定他们在生产环境中运行正常。哦，等会儿。
我们来回顾一下，生产第一。你需要一个开发环境运行一些自动签入测试系统，一个测试环境来做验收及压力测试以防灾难性错误，以及一个生产环境。再多无益。
作者注：最好是你的合作伙伴为你提供一个oneboxes为你的开发及测试环境所用，oneboxes是一些事先配置好的虚拟机，以其来运行这些你所需要的服务，这些虚拟机是一些压缩镜像。当然，oneboxes跟生产环境完全不同。
很无助
“等会儿！我们不能把未经测试的代码扔给客户。他们会勃然大怒的！同样也不要让我们公布未正式公开及未认证的合作方代码。你疯了吗？”闭嘴，成熟些吧。生产第一。现在的问题是配置生产环境对未公开代码进行测试与认证。
这种解决方案称为“持续部署”（continuous deployment）。这个概念很简单：将多个创建（build）部署到生产环境中去，使用自定义的路由定向。就像面向规范服务（regulating service）（而不是源码）的源码控制系统。这种系统没有构建进Azure及其他云系统是不可想象的。
实现持续部署有很多种方法，这些方法与部署系统及自定义路由的灵活性有本质的不同。但是，持续部署的实现要相对简单。
最困难的部分是数据处理，必须使其在各种创建间保持有效。然而，如果一项服务被设计成在一项新的创建部署后能执行至少一次回滚，即使这项新创建使用了新数据，那么这项服务在一个持续部署的环境中就能运作良好。
作者注：你还需要注意多种创建间设置的多样性问题。这有点棘手，但还不算很糟。理想情况下，你的设置不会时常改变。如果新创建依赖于.NET Framework或操作系统的最新版本，那么这些新创建必须放到新配置的机器上——但你没必要对持续部署做什么更改。对于数据及模式的变动，我强烈建议不要配置多种数据库。相反，在数据行、列及表增加时应用模式的变更而不要在数据行、列及表变更或删除时应用模式。如我之前所说，你必须这样做，即使你不采用持续部署。
当你必须对模式做重大变更时，成熟的做法是做双版本准备：
第一种版本，创建一个能认识老的及新的模式的版本，并进行对应处理。（这并不是个新鲜的重大功能，它只是具有一种处理两种模式的能力。）
第二种版本，当第一种版本稳定后，推出一个依赖于新模式的版本。现在，如果还有问题，你就有了一种安全的回滚机制。
怎样才能办到
如何在集成测试、合作方测试、压力测试及认证环境中使用持续部署？我们来逐个讲讲。
集成测试你在生产环境中部署了新的创建，但只是设置你们的工程师团队与创建间的自定义路由来指定路径（默认本来是没有路由的），其他所有人都在等候着你最终的公开版本。这种技术叫做“曝光控制”（exposure control）。那现在你的团队可以在一个有着实际生产数据及实际生产负载（采用未向客户公开的创建）的真实生产环境中测试了。
作者注：你需要一个功能强大的诊断工具来分析你在生产环境中发现的错误，不管是不是持续部署都该如此。
合作方测试合作方将他们的新创建部署到生产环境中，并只在他们的工程师团队与他们的创建间设置自定义路由来指定路径。其他人看不到变更。现在合作方可以在没人（包括其竞争者）知道其工作进展的情况下对你的生产服务进行测试，压力测试你在生产环境中部署了最新创建并完成测试。一旦通过验证，你通过“曝光控制”逐步提升最新创建的实时路由负载——先是1%，再是3%，然后10%，30%，100%，你在这个过程中监测服务状态。如果你的服务出现错误信号，就记录下数据及路由负载回到前一个版本中（实时回滚）。
认证合作方在生产环境中部署他们的最新创建并对它们进行测试。一旦这些创建被验证，合作方使用“曝光控制”将认证团队定向到他们的最新创建上。在客户或竞争者看到他们的最新进展前，这个认证团队在生产环境中对他们的创建进行认证。当这些创建通过认证后，合作方可以选择何时将实时路由定向到他们的创建上。
Beta红利！你部署一个Beta版创建时，一旦它通过验证，你利用“曝光控制”将Beta版用户定向到Beta版创建上。
改良红利！你另外部署了一个当前创建的改良版。当它通过验证时，你使用“曝光控制”将一半的实时路由负载定向到你当前的创建上，将另一半定向到新的改良版上。你利用在使用模式（usage pattern）中见到过的这种差别提升服务的效率。
自动回滚红利！在你将所有的实时路由负载定向到新创建上后，你将之前的版本留在原处。将你的健康检测系统与曝光控制系统连接。如果你的健康检测系统提示错误，则曝光控制系统将马上自动重定向路由至你之前的版本——无论白天还是晚上。
我们现在不在堪萨斯州了
十多年前，在我们进入企业软件领域后，微软的工程师从中受益颇多。遗憾的是，这些经历对我们最近的面向服务工程却产生误导，迫使我们以服务质量的名义创建了多余的环境。
维护不相干的环境耗尽了我们的带宽、能源及硬件资源，并给工程师带来沉重的负担，而没有带来真正的质量保证。该停止了，庆幸的是当团队迁移至持续部署后这种趋势行将中止。
有了持续部署，你满足了服务质量而无需外加成本。同时，这为你的服务质量的提高，以及你与你内部或外部合作伙伴的合作带来太多好处。
该停用源代码控制系统来进行软件开发了。这个想法可不是开玩笑，也不是非分之想。持续部署为服务带来了相同的效能。日后的某一天，当我们回想今日，会惊奇：人们怎么可以没有它？
作者注：目前，在微软，我所知道的只有Bling与Ads平台拥有基于持续部署的产品。亚马逊拥有业界最闻名的系统。
我的团队目前正在创建一个非常简单的持续部署环境。这个环境使用一种onmachine的IIS代理服务器提供曝光控制，这样可以在同一台机器上对同一种角色使用多个软件版本。
从工程团队的角度看，我们仍然一如既往地为同一台机器部署同一种角色。不同的是现在这些机器安装的是这些角色的不同软件版本，并通过曝光控制由我们选择版本自主定向路由负载。
