如何才能做到持续交付？

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

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

　　​什么是持续交付?

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

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

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

　　第一，它让你能更快地验证新业务方案的结果，并根据真实的用户反馈进行调整。尤其是当业务方案有根本性缺陷时，你一定希望能尽早地发现，而不是花数月或数年的时间和大量的金钱来实施计划后，才知道存在问题。

　　第二，与项目结束后的一次性大版本发布相比，它能提供一种大幅降低交付风险的交付流程，而且成本的投入也更加具有可预见性。

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

　　第一，项目经理们能看到项目的真实进度，因为，此时的“完成”是指：运行于真实生产环境中的可工作的软件已经为用户带来价值。

　　第二，通过规律性增量发布，大大减少了每次发布的风险。

　　实现持续交付

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

　　配置管理：

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

　　第一，要能以全自动化的方式，构建、测试并部署你的应用。为了做到这一点，源代码、测试脚本、构建与部署脚本、数据库迁移脚本等统统要纳入到版本管理。

　　第二，应用程序的部署时及运行时配置项需要以某种统一且集中地方式管理起来。

　　第三，要能用全自动化的流程在每种环境上创建或者进行配置变更。

　　第四，所有的开发工作必须在主干上完成，而且，能够对较大的特性或重构做增量实现，以便应用程序一直保持在可工作状态。如果必要的话，没有开发完的特性可以利用配置开关，使用户无法通过界面或公共接口使用它。

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

　　敏捷测试

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

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

　　部署流水线

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

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

　　通过持续交付来管理项目

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

　　重新调整你的直觉

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

原文转自：http://www.ltesting.net