持续交付：价值主张

软件工程快速地从敏捷开发到持续集成、再到持续交付的发展，如何才能跟上互联网大规模协作的软件进程？持续交付不是做不做的问题，而是不得不做、如何去做、如何做好的问题。

英文链接：Continuous Delivery: The Value Proposition

　　过去十年中，一个划时代的改变就是：基于Web的业务模式对传统企业业务模式的冲击。亚马逊就是历史最长，也最明显的例子之一，而越来越多的公司（从航空到金融服务）开始依赖软件打造其竞争优势了。

　　依靠软件来运行的业务有两个关键组件：一是你想如何改变世界的愿景，二是尽早收集用户的反馈。精益创业运动特别强调反馈的重要性，这不仅仅体现在创业公司。像亚马逊、NetFlix、和脸谱这样的公司也持续不断地对其网站进行小步改进，从而增加收入，并改善网站用户的体验。

　　什么是持续交付？

　　想在用户与项目团队（包括客户或者Product Owner）之间建立紧密的反馈环，依赖于你是否有这样的能力，即：通过持续交付新的软件版本，验证新的想法和软件的改动，并能衡量这些改动对收入的影响。

　　对于很多需要几个月时间才能发布新版本的公司来说，在一天之内发布数次似乎是天方夜谭。然而，遵循《持续交付》一书中的原则与实践，一些原来一 年才能发布几次新版本的公司，也已经能在一个月内发布数次，或者更频繁了。这是一种巨大的竞争优势，而且意味着，在时间和精力方面减少了大量的浪费。

　　实际上，持续交付有两个至关重要的业务收益：

• 第一，它让你能更快地验证新业务方案的结果，并根据真实的用户反馈进行调整。尤其是当业务方案有根本性缺陷时，你一定希望能尽早地发现，而不是花数月或数年的时间和大量的金钱来实施计划后，才知道存在问题。
• 第二，与项目结束后的一次性大版本发布相比，它能提供一种大幅降低交付风险的交付流程，而且成本的投入也更加具有可预见性。

　　另外，对于IT管理来说，它还提供另外两种好处：

• 第一，项目经理们能看到项目的真实进度，因为，此时的“完成”是指：运行于真实生产环境中的可工作的软件已经为用户带来价值。
• 第二，通过规律性增量发布，大大减少了每次发布的风险。

　　实现持续交付

　　为了能够成功实现持续交付，需要依赖于两个基础，一是技术基础，二是组织基础。而这两个基础有三大支柱：（1）全面的配置管理；（2）敏捷测试；（3）部署流水线。

　　配置管理：

　　就配置管理而言，为了实现持续交付，有四个关键点：

• 第一，要能以全自动化的方式，构建、测试并部署你的应用。为了做到这一点，源代码、测试脚本、构建与部署脚本、数据库迁移脚本等统统要纳入到版本管理。
• 第二，应用程序的部署时及运行时配置项需要以某种统一且集中地方式管理起来。
• 第三，要能用全自动化的流程在每种环境上创建或者进行配置变更。
• 第四，所有的开发工作必须在主干上完成，而且，能够对较大的特性或重构做增量实现，以便应用程序一直保持在可工作状态。如果必要的话，没有开发完的特性可以利用配置开关，使用户无法通过界面或公共接口使用它。

　　同时，有效的配置及发布管理也依赖于整个交付过程中开发团队与运维团队（包括DBA）之间的紧密合作。为了确保运维需求被纳入项目考虑范围，并 让应用程序在开发初期就能部署到类生产环境中进行单一功能或跨功能测试，运维人员应在项目开始阶段就成为交付团队的一员。这种协作也正是DevOps运动所倡导的重要的文化转变之一。

　　敏捷测试

　　持续交付依赖的第二个支柱是敏捷测试方式。当然，它也同样包含技术和组织两方面。从工程角度来看，各个层次上的自动化测试是 必不可少的，包括单元级别、组件级别，系统级别（功能与非功能测试）。要确保做到：如果自动化组合套件全部成功通过了，那软件本身就达到了可发布质量， 即：在生产环境中没有回归缺陷，满足业务需要——包括容量和可用性方面的要求。

　　敏捷测试要求在整个交付过程中的质量内嵌。也就是说，测试不再是一个“阶段”，而应该是在整个交付过程中持续发生的一种活动。同样，软件的质量 不再只是测试人 员或QA的责任，而是整个交付团队的责任。测试人员与分析人员应该在一起，共同创建可测试的验收条件。作为开发过程的一部分，测试人员与开发人员应该合作 创建自动化的验收测试，用于验证所开发的内容满足验证标准，这叫做“验证测试驱动的开发（acceptance test-driven development）。开发人员要负责维护验收测试，并确保它们一直可以成功通过。

　　部署流水线

　　持续交付的第三个支柱是部署流水线。从本质上讲，部署流水线是现有交付过程的一个模型，是整个价值流的一部分，即从提交到发布的那一段价值流。可以用像Go这 样的工具对其进行建模。对于应用程序的任何修改（包括配置）都要从头到尾通过这个部署流水线，即先对系统进行构建，并基于该构建产物运行自动化测试，然后 放到某处，以便后续部署到测试环境和生产环境。可以把部署流水线看做是持续集成的一个延伸，即：它将持续集成从开发团队扩展到了测试和运维团队。

　　用来建模和管理部署流水线的工具会记录每一次构建历史，它会记录每个构建所对应的版本控制库中的版本号，谁把它部署到了哪个环境，什么时候部署 的，部署的结果是“成功”，还是“失败”。这个部署流水线应该强制你的部署工作流（包括认证和授权），并能对整个交付流程进行审计。由于这个流水线是对你 的开发及部署过程进行建模，所以，它为发现流程瓶颈，持续改进交付过程提供了丰富的数据支持。

　　通过持续交付来管理项目

　　毫无疑问，对于刚刚接触持续交付的团队来说，对其所要求的纪律性会感到吃惊。很多直觉上应该如何管理项目的方式（包括团队成员之间如何互动）都 需要改变。对团队来说，当实施持续交付时，和所有的敏捷方法一样，最重要的事情是通过回顾，持续反省他们正在做的事情，并对工作方式和过程做增量式的改 变，并不断地改进它。

　　重新调整你的直觉

　　每个项目天生都有一种节奏和风格。传统的交付项目在项目开始和中期，总会有一个漂亮而体面的进度报告。然而，当到了某个时间点后，客户和管理层 常常会有一些令其不悦的发现：尽管大部分内容都“开发完成”了，但在集成阶段，部署到具有现实负载的类生产环境中的应用程序总是不能工作得很好。

　　此时，这个项目就进行了所谓的“两难境地”，或叫“死亡行军”，人们在很大的压力上加班工作，试图修复整个系统。这令每个人都极不满意，而事实上， 在某些领域，这种失控模式已经成为一种家常便饭。

　　在那些实践持续交付的项目中，开始时进展可能比较慢。因为项目一开始要建立基础设施，对构建、测试和部署做自动化，并在得到成功构建的产品后， 在类生产环境中执行验收测试。这让团队成员，尤其是刚接触它的管理者，感到不舒服。然而，这正说明它起作用了。持续交付的影响表现在它把痛苦提前了，从而 让交付过程更加平稳、真实且可度量。

　　你原来体会到的是“开发完成“，与“真正完成”不一样。现实中，真正的“完成”是指发布给用户，或者至少在集成环境上严格地进行验收和回归测试 后，在类生产环境中向客户演示。在新功能开发完后，其实还有很多工作要做：交付过程中的这部分被叫做最后一哩。持续交付坚持认为：“只有过了这一哩”，工 作才算完成，根本就没有“完成了百分之五十”这个说法，所以，这让整个交付进度看上去比较慢。

　　然 而，通过持续交付，你能得到可持续性。首先，因为持续交付意味着软件一直处于可发布状态，所以可以把原来的测试与集成阶段移掉，这就会大大降低项目风险。 在这两个阶段，经常会发现严重问题，甚至是整个架构的缺陷。而修复这些问题的时间则很难预期。通过持续交付，这些问题在交付过程的早期就会被发现，些修复 成本往往比较低。

　　其次，对于新开发的特性来说，能更快地从客户和用户那里得到反馈。通过增量开发和持续发布给用户，你能在特性创作过程中就得到早期反馈，并不断调整。这样，软件的演进可以更快速地满足用户的需求。

　　设法进行增量开发

　　在主干上增量开发时，为了能够将大的特性拆分成小的、有价值的、可测试且相对独立的用户故事，需要分析人员、测试人员及开发团队的紧密合作。这么做，有几个好处。

　　可能最重要的好处就是，它促使团队将一个功能里，关键的部分和非关键部分区分开来，这让客户能在更小的粒度上做决策。将一个“必须做”的特性分解成多个小的、可增量开发的小需求，能更有效地区分出哪些是该功能的核心，哪些是外围需求。

　　然后，你可以将功能的核心部分（最初的最直接的实现）给用户进行测试，并找出用户接下来想做什么。这样可以给客户一些具体的数据，让他们更好地 对该功能的剩余工作进行优先级的排序。当然，也很可能在他们看过以后，客户希望将后续的时间花在其它功能上了。而且，假如客户看过以后。认为这个特性没有 什么价值，你可以马上停下来，不再浪费精力在这上面了。

　　增量开发依赖于每个人每天都能够提交一次，这样，应用程序才可以持续集成。对于那些习惯于在长生命周期分支上开发新特性或每个分支对应一类客户 的团队来说，这看上去是不可能的。好消息是，在主干上开发是可行的，对于很大的团队也是可行的。坏消息是，它要求应用程序由松耦合的组件构成，并有良好的 架构。它还要求，可以通过配置项在UI上能控制特性的开与关，这样，你才能可以灵活地控制，当功能准备好后，再打开开关。即使一些新功能只开发到一半，你 也能持续地发布你的软件。

　　然而，这样做的收益也很大：你能持续不断地把已经做好的功能交付给客户，而不用绞尽脑汁地猜测哪个功能有价值。频繁地发布有价值的新功能是提高收入的 最好方式。

　　我怎么知道我是不是真的在持续交付？

　　持续交付是否需要一个像“Nokia 测试”那样的checklist呢？实际上，没有那个必要，因为有一个非常简单的方法来验证，你是不是真的在持续交付：你的软件是不是一直处于产品可发布 状态。你只要按个回车键就可以把 它发布给用户。如果你的发布过程很痛苦，而且不太频繁，并且在发布之前还有一个充满风险的集成阶段，那么你就没有在做持续交付。

　　持续交付中最重要的度量是周期时间（cycle time）：从决定实现某个想法开始，到将其发布给用户为止这段时间长度。有几个原因让它成为一个很重要的度量：

• 第一，这是一个全局度量指标，用于度量整个过程的有效性。
• 第二，这是一个团队度量指标，而不是一个个人度量指标——只整个团队关注于改进交付过程，才有可能改变周期时间。

　　部署流水线提供了部分答案：部署流水线的实现会给你提供一些你需要的数据，主要是从提交到发布这段时间的。那么，只要你有一种方式将提交与特性关联起来，你就可以看到某个特性的周期时间。如果现在的工具不能让你收集这些数据，那就找一个去吧。

　　这样，你就可以制定一个持续改进流程，应用约束理念 ，或者使用看板，在交付过程中找到瓶颈，并想办法移除它们。持续交付可以也应该同样使用持续改进的方式减少成本，提高收入的增量地方式实现。