从持续设计到持续交付：完善循环

通常情况下，软件交付中的创新和产品构思之间并不总会互相影响。尽管如此，随着对产品新功能的需求不断增多，及对应产品生命周期的缩短，甚至商业模型，也都使得将持续设计和持续交付置于同一循环以实现全面的交付成为必需。由于缺少好的名字，我们就暂就时叫本文为创新循环，循环的每一个阶段如下所示：

1. 选择一个构思
2. 将该构思提炼成一个可测的假设
3. 选择完成该构思所需的功能
4. 开发并测试这些功能
5. 开发和测试那些衡量标准以证实该假设是否可行
6. 将构思发布到生产环境
7. 对该构思成功与否进行衡量
8. 重复这一循环。

不出意料，支持该方式需要应用程序在以下方面进行创新：度量和分析，基础架构，测试，试验型设计，持续设计及支持持续交付的流程和工具。在本文中，我们将介绍维持该循环所要求的重要创新。以下涉及的每个话题都可独立成文或者涉猎更多，请将此调查问卷作为一个引子，激发大家去更多地了解这些话题。

度量和分析

度量是有风险的，它很容易产生反效果，激励坏行为。尽管如此，度量却是以上我们所描述循环的一个主要方面。软件系统中关于具体内容的构想的定义不仅在于软件具体行为，也在于如何知晓该构想的好坏。我们可以参考一个具体实例：市场部有人认为如果改变他们的网上购物流程，其网上营业额将会提升 20%。该例子的构想是改变流程，而可测性的假设就是用户使用新流程后，会有高于之前流程 20% 的人倾向购买。在这种情况下，其度量就很简单，我们需要去测量每个流程客户的购买结果。我们可以随机性地将用户分配到不同的流程，然后评定各流程是否达到它的目标。为了完成这个度量，我们要保证我们记录下每个流程用户的使用情况和销售结果。在测试的最后阶段，我们就会知道该营销想法好坏与否。

试验型设计

有时，什么是正确的度量或需要哪种类型的分析来评估一个构想的价值，并不显而易见。比如：试图提高生产力的构想，就可能很难去度量。提供给系统所有者对其构想成功与否的反馈，对新需求的优先级排定和引导系统改进起着至关重要的作用。

设计可测试性假设有效的方式是：设计一系列试验以验证新功能是否交付了预期结果。因此，我们从新功能的预期结果和其对系统行为带来的影响来决定。设计试验的关键是保证度量了新功能的真实影响。拿上述改变购买流程的例子来讲，度量和比较用户使用新旧流程比单方面查看历史数据提供了更有效的依据。

演变型基础架构

要使该循环有效执行下去，部分地要求快速调整系统以尝试新的想法。在理想世界里，我们能够预见所有对系统可能想要的修改。现实中，一切改变都是不可预测的。用户期望，商业环境，竞争对手情况，规章制度等都在一个组织管辖范畴之外。因此不论改变是否可预见，我们都需要能够适应。演变型基础架构和紧急设计是敏捷软件开发采取的方式，能让不可预计变化变得尽可能简单和安全。

支持演变型基础架构和紧急设计的测试将在下个章节涉及。通过认清由于系统新加功能所产生的重构机会，紧急设计关注于保持代码可维护性与干净整洁。与之相反，演变型基础架构关注于系统的构架因素，包括技术选择和不同架构元素间的接口设计。

在这种情况下，演变型架构的目标包含独立开发系统不同部分的能力，即使它们需要相互交互。我们通过对功能的合理封装，连同合同测试里记录的每个系统对其它系统行为的影响等途径来将其实现。为每个开发团队提供这样的测试能让他们从一开始就意识到随着系统的开发将不可避免地会遇到不兼容性问题。演变型架构的另外一个目的在于目标数据修改，信息修改，以及某个组件对其他组件实现的交换。

测试

在演变型架构章节，我们讲述了支持该变革循环重要的测试风格。尽管如此，很多其他测试方式对支持该循环也至关重要。彻底有效的单元测试对支持演变式设计是至关重要的，而且也为添加新功能而不影响当前功能带来了更多自信。同样，一个彻底的回归测试集也在不同粒度层提供了同样的保护。

一个完整的测试策略对于参与到该创新循环的系统，保证了在不影响旧功能的前提下新功能的正常使用。该测试应包含功能测试以外的技术型测试（压力，环境等）。同样重要的，测试这一功能对该构想的度量的支持也应该包含在测试策略里。为了确保该循环的进行，自动化测试至关重要。手动测试循环一般都很长，手动测试应该关注于核心领域，并更倾向于探索性。

持续设计

值得兴奋的是设计越来越关注于客户和用户体验。与软件开发其它方面一样，以用户为中心的设计也在学习如何更加以敏捷为导向。同架构和应用设计一样，对用户体验框架的设定，一些前期思考是必需的。尽管如此，需再次强调的是，不应集中太多精力在初始框架的确定上，应该同架构和设计一样，让设计随着用户需求及期望的变化而不断改变发展。

持续设计允许用户体验通过系统演变不断探索来获得启发。该方式也将我们的注意力集中在功能都将为用户系统交付了哪些价值。希望通过以用户为中心的方式来防止系统常见的功能臃肿现象。

持续交付

与本调研文章的其它话题一样，持续交付的复杂性和全面性能占据多个篇幅，而非几个段落。但是，持续交付背后的概念所提供的机制能使该创新循环执行下去。在这里，与持续交付原理最相关的是快速部署到生产环境，缩短了构想与其价值回馈的循环时间。

完成快速部署需要持续交付多种技术，包括架构自动化，构建自动化，部署和回滚自动化，数据集成自动化，当然还有之前提到的测试自动化。每个技术对支持以下步骤都是必需的：快速开发新功能，快速测试新系统，快速安全部署产品，快速安全回滚以防止系统没有如期工作或新功能被证实为坏主意。

演变循环

最后，上述创新循环的目的在于允许组织能快速测试构想。如果没有该循环，组织就需要在执行某个构想上花费很多资源，而这也意味着只有少数构想被尝试，因此，组织能成功实现的就仅限于某些特定的构想。通过减少费用、时间，和尝试新构想所带来的风险，该创新循环允许组织尝试更多，从而加大了找到更多构想潜在价值的可能性。

演变型架构和全面的测试，连同敏捷软件开发的其它实践，减少了执行某个构想的开发时间。持续设计致力于某一功能应如何与系统其他模块集成，并为如何度量某一想法成功与否提供了建议。试验型设计和合理的使用度量完成了所需的回馈循环以判定某想法的成功与否。持续交付所提供的机制允许将所有这些工作集成起来以完成该变革循环。

通过减少试验所带来的风险和费用，为组织持续地为其员工和客户提高他们的服务提供了基础。我们认为完成该变革循环能为组织提供了一个非常具有竞争力的优势。

关于作者

Dr.Rebecca Parsons 现为 ThoughtWorks 的首席技术官。她拥有长达 20 多年的软件应用开发经验，其从业领域涉及电信到新兴互联网服务。她在领导创建大型分布式对象应用，基于应用的服务以及集成各种不同系统方面拥有广泛的经验。目前她也是敏捷联盟董事会的主席。

加入 ThoughtWorks 之前，她是中弗罗里达大学计算机系的助理教授。她同时也是洛斯阿拉莫斯洛国家实验室并行与分布式计算，通用算法，生物计算以及非线性动态系统的博士后。她在 2010 年休假时曾在 UNICEF 位于乌干达坎帕拉的创新实验室工作过。

Rebecca 获得布拉德利大学的计算机科学以及经济学学士学位，莱斯大学的计算机硕士以及博士学位。

参考英文原文： Continuous Delivery with Continuous Design: Completing the Cycle

感谢陈菲对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。