迈出持续交付的第一步

持续交付整合了许多实践，这些实践的数量可能令人生畏。但是通过执行一些基本的步骤就可以让开发者立刻受益。我们应该如何迈出持续交付的第一步呢？AccuRev 的首席技术官 Dave Jabs提供了自己的建议。

Dave 认为能够在开发和交付方面表现优秀的软件开发组织将在商业中拥有战略优势。然而，很多开发组织很难做到及时交付软件。“持续交付”这一实践形式越来越成为准时交付软件工作的重要组成部分。持续交付定义了一组旨在消除机械障碍、提高交付速度以响应市场需求的实践行为。他最欣赏来自 Thoughtworks 的 Jez Humble 对持续交付的定义，他的书籍也开创了持续交付的先河。他说：“我的软件交付哲学的精髓是构建一个随时可以用于生产的软件。我们称之为‘持续交付’是因为我们不断运行一个部署管道来检测这个软件是否在交付状态。”

持续交付并非持续部署、也不是持续发布或者某些只有云计算应用程序需要考虑的东西。持续交付使用一组包括分段软件开发和交付过程的关键准则。过程中的每一阶段都设有一系列不同标准。在软件进入下一阶段前必须对当前阶段标准进行验证。这些过程中的测试、软件部署和推广均采用自动化模式。基于阶段的过程最终形成了交付管道。新软件可以在交付管道持续运行，并在运行过程中不断被验证以逐步获得更高的质量。

因为持续交付并非工具或产品，所以实现它是困难的。能实现成功的持续交付的方法必然是一个完整的方法，它必须协调好技术、过程、人和价值的关系。这意味着团队心态的转变，以及开发流程、开发工具的改变。要想做好持续交付，开发组织也需要做出改变。实现卓越的持续交付并不容易，但它的回报是非常诱人的：开发团队将达到先前认为不可能的运行速度。

Dave 认为，持续交付的全局概念并不新鲜。实际上，第一个敏捷原则就声明：“最高优先级是通过早期和持续交付有价值的软件满足客户需求。”尽管熟知这个概念，许多公司——甚至一些致力于敏捷过程的公司——都很难做到持续交付。

持续交付路线图的第一站是为开发和交付管道建模。当下许多开发组织由互相不联系的团队构成。如果你想做到持续交付，你需要保证管道从头到尾是连续的。

实现持续交付需要开发组织实现一个多步骤方法，Dave 总结道：

1. 为现有流程建模并测量其周期时间
2. 识别过程中的延迟
3. 制定行动计划将当前延迟降为最小，消除潜在的延误

通过执行这些步骤，Dave 认为，开发组织可以消除开发工作与运营工作之间的等待延迟，以获得一个单一、统一标准，概念上可以执行各种交付软件的管道。持续交付是一个旅程，而不是一夜之间的产物，因为开发组需要做出技术、过程、文化、人员等方面的巨大改变以实现完整的管道——而且进行这些改变是需要时间的，其耗时常常多于一年。那么软件开发组织要从哪里入手呢？Dave 认为公司最初应当集中攻克的三个基本领域如下：

• 需求管理：需求必须被分解为最小的交付单元；根据增量交付来制定和管理开发方案。
• 测试 / 验证：QA（测试 / 验证）环节必须是基于经验的、结构化的、有组织的、自动化的。此外，良好、持续的集成是持续部署的先决条件。
• 交付技术：首先是版本控制。再现性的软件构建是一种常见的方法，然而再现性的部署常常丢失。之后是自动化交付。持续此操作直到它成为一个一键无阻的过程。

很多软件开发公司在实现持续交付时都遇到了难以克服的障碍。Dave 认为，他们之所以会遇到这种障碍是因为他们现有的产品并没有遵循持续交付定律进行开发。好消息是，他们现在开始改变了。公司开始制定目标、宗旨，执行实践，这些将使他们获益——从在最初的一些小利益到最终的理想状态。

在需求管理方面，公司在定义易懂的、易管理的、可交付的小交付故事（story）时常常会遇到问题。Dave 提供的解决方案是设定目标，让每一个故事精简，然后集中精力在短的时间周期内不断改进故事的写作过程直到故事完成。在一组相关的故事完成前，可以通过使用功能切换进行故事隐藏或通过 A/B 测试判断一组故事的可用性。

在测试 / 验证方面，Dave 指出，在当今的软件开发测试中，大部分公司在 GUI 测试的投入巨大。这种做法其实并非最优。

公司应该把大部分测试集中在单元测试，因为单元测试的测试覆盖率是最大的。在单元测试中，重点应进一步放在集成测试。在集成测试中，开发者通过执行一系列小的集成测试以确保各组件可以共同工作。GUI 应当是投放精力最少的测试，因为 GUI 测试通常是脆弱、缓慢、不可靠、性价比最低的。这种测试策略将带来更小的循环周期，更高的质量，更低的测试成本。

另一个常见的问题是扩展持续集成。Dave 认为，随着开发的步步深入，开发者可能会遇到越来越多并发的变化，花在构建和测试上的时间会越来越长，这些都可能导致失败的构建。最糟糕的情况是在一个单一主线进行构建时，结果不是大部分工程工作而是大部分工程都失败。这种做法就不是持续交付。更糟糕的是，这种不稳定的主线会影响所有的开发者，并且将他们的成果大打折扣。

公司可以通过采用两项主要技术来实现大规模持续交付。每一项技术都被设计为“分而治之”的策略，这些策略允许开发者关注对持续交付有显著影响的特定区域：

组件或服务架构：公司可以选择将他们的软件变为组件或者服务框架。这些组件可以独立部署，独立生产，不受其它组件的影响。它们有清晰的接口，可以兼容多个版本的组件。通过这种结构，开发者可以运行相互独立、互不干扰的开发工作和交付管道。这种结构提供了工程的可扩展性。

多团队持续集成：在这种方法中，开发者通过采用多个团队小组进行开发的方式获得可扩展性。开发者在各组进行整合和测试步骤时进行工程整合，最终实现部署管道。多级持续集成的关键是将管道开发和集成测试分为几个阶段。开发组织可以依据团队分支、特征分支、构建（每天、每周等）和主线定义各阶段。通过在各阶段使用集成测试开发组织在一定程度上扩大了测试的覆盖范围，提高了测试的连续性。测试连续性允许代码在管道里流动，加快问题识别速度，让开发者更容易分析、解决问题，这些都降低了修正问题的成本。