软件工程快速地从敏捷开发到持续集成、再到持续交付的发展，如何才能跟上互联网大规模协做的软件进程？持续交付不是作不作的问题，而是不得不作、如何去作、如何作好的问题。html
英文连接：Continuous Delivery: The Value Propositionios
过去十年中，一个划时代的改变就是：基于Web的业务模式对传统企业业务模式的冲击。亚马逊就是历史最长，也最明显的例子之一，而愈来愈多的公司（从航空到金融服务）开始依赖软件打造其竞争优点了。数据库
依靠软件来运行的业务有两个关键组件：一是你想如何改变世界的愿景，二是尽早收集用户的反馈。精益创业运动特别强调反馈的重要性，这不只仅体如今创业公司。像亚马逊、NetFlix、和脸谱这样的公司也持续不断地对其网站进行小步改进，从而增长收入，并改善网站用户的体验。架构
什么是持续交付？运维
想在用户与项目团队（包括客户或者Product Owner）之间创建紧密的反馈环，依赖于你是否有这样的能力，即：经过持续交付新的软件版本，验证新的想法和软件的改动，并能衡量这些改动对收入的影响。工具
对于不少须要几个月时间才能发布新版本的公司来讲，在一天以内发布数次彷佛是天方夜谭。然而，遵循《持续交付》一书中的原则与实践，一些原来一 年才能发布几回新版本的公司，也已经能在一个月内发布数次，或者更频繁了。这是一种巨大的竞争优点，并且意味着，在时间和精力方面减小了大量的浪费。测试
实际上，持续交付有两个相当重要的业务收益：网站
另外，对于IT管理来讲，它还提供另外两种好处：this
实现持续交付google
为了可以成功实现持续交付，须要依赖于两个基础，一是技术基础，二是组织基础。而这两个基础有三大支柱：（1）全面的配置管理；（2）敏捷测试；（3）部署流水线。
配置管理：
就配置管理而言，为了实现持续交付，有四个关键点：
同时，有效的配置及发布管理也依赖于整个交付过程当中开发团队与运维团队（包括DBA）之间的紧密合做。为了确保运维需求被归入项目考虑范围，并 让应用程序在开发初期就能部署到类生产环境中进行单一功能或跨功能测试，运维人员应在项目开始阶段就成为交付团队的一员。这种协做也正是DevOps运动所倡导的重要的文化转变之一。
敏捷测试
持续交付依赖的第二个支柱是敏捷测试方式。固然，它也一样包含技术和组织两方面。从工程角度来看，各个层次上的自动化测试是 必不可少的，包括单元级别、组件级别，系统级别（功能与非功能测试）。要确保作到：若是自动化组合套件所有成功经过了，那软件自己就达到了可发布质量， 即：在生产环境中没有回归缺陷，知足业务须要——包括容量和可用性方面的要求。
敏捷测试要求在整个交付过程当中的质量内嵌。也就是说，测试再也不是一个“阶段”，而应该是在整个交付过程当中持续发生的一种活动。一样，软件的质量 再也不只是测试人 员或QA的责任，而是整个交付团队的责任。测试人员与分析人员应该在一块儿，共同建立可测试的验收条件。做为开发过程的一部分，测试人员与开发人员应该合做 建立自动化的验收测试，用于验证所开发的内容知足验证标准，这叫作“验证测试驱动的开发（acceptance test-driven development）。开发人员要负责维护验收测试，并确保它们一直能够成功经过。
部署流水线
持续交付的第三个支柱是部署流水线。从本质上讲，部署流水线是现有交付过程的一个模型，是整个价值流的一部分，即从提交到发布的那一段价值流。能够用像Go这 样的工具对其进行建模。对于应用程序的任何修改（包括配置）都要从头至尾经过这个部署流水线，即先对系统进行构建，并基于该构建产物运行自动化测试，而后 放到某处，以便后续部署到测试环境和生产环境。能够把部署流水线看作是持续集成的一个延伸，即：它将持续集成从开发团队扩展到了测试和运维团队。
用来建模和管理部署流水线的工具会记录每一次构建历史，它会记录每一个构建所对应的版本控制库中的版本号，谁把它部署到了哪一个环境，何时部署 的，部署的结果是“成功”，仍是“失败”。这个部署流水线应该强制你的部署工做流（包括认证和受权），并能对整个交付流程进行审计。因为这个流水线是对你 的开发及部署过程进行建模，因此，它为发现流程瓶颈，持续改进交付过程提供了丰富的数据支持。
经过持续交付来管理项目
毫无疑问，对于刚刚接触持续交付的团队来讲，对其所要求的纪律性会感到吃惊。不少直觉上应该如何管理项目的方式（包括团队成员之间如何互动）都 须要改变。对团队来讲，当实施持续交付时，和全部的敏捷方法同样，最重要的事情是经过回顾，持续检讨他们正在作的事情，并对工做方式和过程作增量式的改 变，并不断地改进它。
从新调整你的直觉
每一个项目天生都有一种节奏和风格。传统的交付项目在项目开始和中期，总会有一个漂亮而体面的进度报告。然而，当到了某个时间点后，客户和管理层 经常会有一些令其不悦的发现：尽管大部份内容都“开发完成”了，但在集成阶段，部署到具备现实负载的类生产环境中的应用程序老是不能工做得很好。
此时，这个项目就进行了所谓的“两难境地”，或叫“死亡行军”，人们在很大的压力上加班工做，试图修复整个系统。这令每一个人都极不满意，而事实上， 在某些领域，这种失控模式已经成为一种屡见不鲜。
在那些实践持续交付的项目中，开始时进展可能比较慢。由于项目一开始要创建基础设施，对构建、测试和部署作自动化，并在获得成功构建的产品后， 在类生产环境中执行验收测试。这让团队成员，尤为是刚接触它的管理者，感到不舒服。然而，这正说明它起做用了。持续交付的影响表如今它把痛苦提早了，从而 让交付过程更加平稳、真实且可度量。
你原来体会到的是“开发完成“，与“真正完成”不同。现实中，真正的“完成”是指发布给用户，或者至少在集成环境上严格地进行验收和回归测试 后，在类生产环境中向客户演示。在新功能开发完后，其实还有不少工做要作：交付过程当中的这部分被叫作最后一哩。持续交付坚持认为：“只有过了这一哩”，工 做才算完成，根本就没有“完成了百分之五十”这个说法，因此，这让整个交付进度看上去比较慢。
然 而，经过持续交付，你能获得可持续性。首先，由于持续交付意味着软件一直处于可发布状态，因此能够把原来的测试与集成阶段移掉，这就会大大下降项目风险。 在这两个阶段，常常会发现严重问题，甚至是整个架构的缺陷。而修复这些问题的时间则很难预期。经过持续交付，这些问题在交付过程的早期就会被发现，些修复 成本每每比较低。
其次，对于新开发的特性来讲，能更快地从客户和用户那里获得反馈。经过增量开发和持续发布给用户，你能在特性创做过程当中就获得早期反馈，并不断调整。这样，软件的演进能够更快速地知足用户的需求。
设法进行增量开发
在主干上增量开发时，为了可以将大的特性拆分红小的、有价值的、可测试且相对独立的用户故事，须要分析人员、测试人员及开发团队的紧密合做。这么作，有几个好处。
可能最重要的好处就是，它促使团队将一个功能里，关键的部分和非关键部分区分开来，这让客户能在更小的粒度上作决策。将一个“必须作”的特性分解成多个小的、可增量开发的小需求，能更有效地区分出哪些是该功能的核心，哪些是外围需求。
而后，你能够将功能的核心部分（最初的最直接的实现）给用户进行测试，并找出用户接下来想作什么。这样能够给客户一些具体的数据，让他们更好地 对该功能的剩余工做进行优先级的排序。固然，也极可能在他们看过之后，客户但愿将后续的时间花在其它功能上了。并且，假如客户看过之后。认为这个特性没有 什么价值，你能够立刻停下来，再也不浪费精力在这上面了。
增量开发依赖于每一个人天天都可以提交一次，这样，应用程序才能够持续集成。对于那些习惯于在长生命周期分支上开发新特性或每一个分支对应一类客户 的团队来讲，这看上去是不可能的。好消息是，在主干上开发是可行的，对于很大的团队也是可行的。坏消息是，它要求应用程序由松耦合的组件构成，并有良好的 架构。它还要求，能够经过配置项在UI上能控制特性的开与关，这样，你才能能够灵活地控制，当功能准备好后，再打开开关。即便一些新功能只开发到一半，你 也能持续地发布你的软件。
然而，这样作的收益也很大：你能持续不断地把已经作好的功能交付给客户，而不用绞尽脑汁地猜想哪一个功能有价值。频繁地发布有价值的新功能是提升收入的 最好方式。
我怎么知道我是否是真的在持续交付？
持续交付是否须要一个像“Nokia 测试”那样的checklist呢？实际上，没有那个必要，由于有一个很是简单的方法来验证，你是否是真的在持续交付：你的软件是否是一直处于产品可发布 状态。你只要按个回车键就能够把 它发布给用户。若是你的发布过程很痛苦，并且不太频繁，而且在发布以前还有一个充满风险的集成阶段，那么你就没有在作持续交付。
持续交付中最重要的度量是周期时间（cycle time）：从决定实现某个想法开始，到将其发布给用户为止这段时间长度。有几个缘由让它成为一个很重要的度量：
部署流水线提供了部分答案：部署流水线的实现会给你提供一些你须要的数据，主要是从提交到发布这段时间的。那么，只要你有一种方式将提交与特性关联起来，你就能够看到某个特性的周期时间。若是如今的工具不能让你收集这些数据，那就找一个去吧。
这样，你就能够制定一个持续改进流程，应用约束理念 ，或者使用看板，在交付过程当中找到瓶颈，并想办法移除它们。持续交付能够也应该一样使用持续改进的方式减小成本，提升收入的增量地方式实现。