互联网行业持续交付的经验

互联网行业持续交付的经验2013-01-17 infoq 胡凯续交付概念的流行反映了业务部门对于更快交付速度的渴望和技术团队对交付这一老大难问题的重视。从持续集成到持续交付，ThoughtWorks一直在积极的实践、思考、总结。这篇文章中我将分享ThoughtWorks一支开发团队在这个领域的收获和总结。

背景

我们的客户是澳洲的房地产搜索门户，每年独立访问者近300万（澳洲人口2000万），年营收近3亿美金，澳洲61％的房产都在此网站展示。我们的团队工作在商业地产、住宅、土地购置等与盈利息息相关的全产品线的核心系统上。

成就

2年前，与大多数“常规”项目一样，部署和发布是一件费时费力、加班加点的活动。作为一家历史超过10 年的互联网公司，已经有大量复杂的业务系统支持着线上业务的正常运转，部署和发布任何一个功能都是牵一发而动全身的复杂活动。对我们的客户来说快起来不是一件容易的事情，但它不得不快，因为竞争对手在频繁的进行商业活动，不快速的求变、求新它将难以保持领先的市场地位。持续交付以及持续交付所支撑的持续创新能力是它必须建设的核心竞争力。

对于 ThoughtWorks，持续交付是增加项目进度的可见性，降低项目“最后一公里”风险的重要工具。这样，投资建设持续交付能力成了合作双方一拍即合的决定。经过了两年的摸索与实践，总接下来，收获主要有以下四点：

一键部署 ：目前的部署流水线从提交开始，到自动运行各种验证，再到最终的安装、配置软件可以做到全程无须人员干预，最终的部署过程可以在几分钟内自动完成。具备了快速部署，持续部署的能力，一天多次部署，一周多次发布就成了顺利成章的事情。

由离岸团队执行部署和发布：中国团队的成员大多是开发人员，对产品环境了解不足；分布式环境让中国的团队没有太多的机会从澳洲团队身上学习如何部署和发布，这样的内忧外困下，得出“由离岸团队来执行部署和发布风险太高”这个结论似乎是很自然的，然而随着持续部署过程越来越熟练和成熟，我们发现上面的结论是与部署手段原始落后的现状息息相关的，一旦发布手段变的高明，由离岸团队部署和发布的风险是完全可以接受的。

业务人员变得更加敏捷：随着部署肌肉的越来越发达，业务人员开始习惯了这样一种对话方式，“唔，这个功能很不错，我们发布出去看看用户是什么反映吧？”，和以往仔细计划、严格执行的风格相比，业务人员的决策过程变成了：

尝试某功能

通过对响应数据的分析，理解功能的市场反应

决定继续开发还是改变方向，不断循环和迭代

通过功能频繁上线，业务人员的思路和做事风格也变的更加敏捷。

业务团队与技术团队理解了部署和发布软件是两个不同概念、两件独立的活动：

2年前，项目部署和发布的时间点从来都是高度统一的，部署结束发布就结束。团队一直没有意识到软件的部署和发布是不同的概念和活动。事实上软件部署是技术概念，包括了：

创建和管理应用所依赖的硬件软件环境

把正确的软件安装到上述环境中

正确的配置产品，使其按照预想的方式运行

软件发布则是业务概念，它包括了决定：

哪些业务功能应该让用户使用？

在什么时间让用户使用？

让哪些用户使用？

必要的市场推广，客户、支持团队培训是否就绪？

通过技术改造，大家明确了部署是一周进行多次，甚至一天进行多次的技术活动，而发布则严格与业务目标对齐，通常以几周为频率。

最佳实践

团队所取得的成就来自于对方法、工具和流程的摸索和应用，我们认为有三个实践对于实施持续交付是至关重要的：

功能开关（Feature Toggle）：持续交付不仅仅意味着使用新工具、新方法。它还意味着从设计和编码阶段就需要作出改变，功能开关是其中一项重要的设计实践，它的目的是方便的打开和关闭某个特性。为什么需要功能开关？因为在持续交付的过程中，团队会遇到下面的情况：

功能没有就绪，还不能让用户使用

功能就绪，但是相关的业务活动（培训，市场活动等）没有就绪，不能让用户使用

业务人员要求功能只开放给部分用户

测试不充分导致的产品缺陷需要关闭功能

功能开关可以用于解决上述问题。它的具体实现多种多样，我们在不同的场景中使用过：

灰度上线：功能部署上线但是把用户可见的操作都屏蔽掉

文件配置：通过配置文件决定某个功能是否对用户可见或关闭

状态数据：通过数据库中的状态值决定某个功能是否对特定用户可见或关闭

编译参数：再编译过程中通过编译参数决定某些特性打开或者关闭

自动化（Automation）：要想频繁的部署、发布而且每次部署都不能出错，是难以离开自动化过程的，我们团队的自动化部署流水线是这样设计的：

本地测试通过后，开发人员提交代码。