大规模项目团队持续集成历程

显示全部楼层 · 2015-9-22 15:53:22

来源：letagilefly.com作者：乔梁发布于：2011年11月15日
这篇文章是我在两年前写的，记录了一个150+人的软件团队（最多时近200人）如何在一个庞大的遗留系统上，通过逐步建立一个持续交付部署流水线，从而达到频繁发布的状态。最终在该团队的持续交付基础设施中，共有260台服务器用于构建、测试和部署（几乎全部是虚拟机）。而这个产品也可以每六周发布一次。

在大规模项目团队中可能遇到的问题对于小规模、短周期的项目来说，团队与持续集成会相处地非常融洽。而对于大规模、长周期项目的初期来说，也不会有太多的问题。此时常见的也是基本的持续集成模式就是：Build->test->package。然而，只要时间稍长一点儿，持续集成就会发出坏味道了。此时的症状包括：

1. 作为开发人员要等很长时间才能知道是否可以提交代码了。如果你遵守“频繁提交”的原则，那么百人团队不间断的提交，会使集成服务器一直处于繁忙状态，而你不得不等待他人的build过了以后，才能看到自己提交的结果。
要等很长时间才能知道我的提交是否通过了；
如果build失败了，要花很长时间才能知道是否和自己的修改相关；
既使提交了fix，也不知道自己的提交是否真的修复了这次构建；
构建经常处于失败状态。

2. 作为测试人员测试人员不知道到哪里拿哪一次的构建产物来进行测试；
发布经理不知道当前各种各样的测试部署环境中，到底部署了哪个版本，包括哪些新功能或修改的bug；
不确定在同一个构建里，所有组件的版本是否都是正确的；

3. 作为项目经理不确定各个测试部署环境中的配置是否都与其上运行的构建相一致；
不确定测试人员测试的是否在正确的运行环境上运行了正确的版本；

4. 其他方面的问题所有的安装部署都需要手工操作。
以上这些问题会给你的发布管理带来无限的问题和风险。那么，是否因为这种“持续闹心”就放弃持续集成呢？回答当然是否定的。Do it more if it hurts you. 不要因问题的暴露而放弃，相反，应该欢呼。因为这反映了发布过程中的问题与风险，是时候解决它们了。

千问 · 2015-9-22 15:53:22

如何解决大规模项目中的持续交付问题由于大项目本身的复杂性，其解决方案也不能一概而论。下面以某大型项目为例，介绍其中的几个解决方法。

1、项目基本信息描述该项目最初就试图建立一个好的持续集成环境和基础。由于是一个遗留系统，费了很大劲儿，才能够得到可工作的软件。然而，由于队伍不断壮大，而且环境也在不断变化，持续集成很快就无法达不到其预期目标了。怎么办呢？

项目背景:
项目是一个具有可配置性的Web 门户产品，面向不同行业的市场，可自己定制门户。该项目有一个遗留的代码库，而且可以肯定的说，在今后的一年半之内是无法摆脱这个遗留代码库的。而且，很多紧耦合的、不必要的臃肿代码，同时根本不存在有价值的测试代码。现在我们在逐步地重写代码，但还是不能删除它们，因为某些网站还要依赖于旧代码。事实上，这是一个.NET平台上基于SOA的网站。

开发团队情况：
团队是一个敏捷分布开发团队（三地协作，均有开发人员，且有时差）。整个团队有150多人，分成十几个团队，每个团队都有一个完成的结构（BA/DEV/QA），其中有一个是项目持续集成团队（项目之初，大约有五六个人，工作负荷很大，项目运行一段时间后只要两个人就足够了）。使用SVN做版本管理工具，在Windows2003上使用NAT, MSbuild和batch脚本进行构建管理，最初使用CC.NET做为持续集成服务器，后来使用Cruise(Go)。

初始的持续集成环境：
上面所述的持续集成问题在项目一开始就出现了，因为该项目有一个庞大的遗留代码库，而且使用的基本持续集成方式（build->test->package）而且测试人员手工部署进行各类测试。

其初始的持续集成环境如下所示：

init1.jpg (20 KB, 下载次数: 1)
下载附件
2012-12-6 13:35 上传

千问 · 2015-9-22 15:53:22

第一步目标：尽量减少团队之间影响方法：先化整为零，再化零为整 ————根据团队划分代码（或者根据代码划分团队）。
手段：DVCS＋私有持续集成服务器＋全局持续集成服务器
每个团队都使用GIT做为中间源代码管理工具。这样，团队人员可以先提交到GIT。每个团队有自己的持续集成环境。一但构建成功，触发将代码提交到中心的源代码库，并触发中心源代码的持续集成。有一个专职团队负责全局持续集成的结果跟踪。
益处：
每个团队都可以天天提交代码（如果这些代码没有让自己的构建失败，就说明至少能够通过初步检验）。任何一个团队的构建坏了，并不影响整个项目，而只是一个团队。有一个专职团队负责全局，不用每个团队都停下来。如果全局持续集成失败了，不用所有的团队停下。

process.jpg (74.6 KB, 下载次数: 3)
下载附件
2012-12-6 13:37 上传

第二步目标：提高反馈速度方法：化整为零，再化零为整————测试分组运行。
手段：并行化与中心仓库（Cruise的并行化与中心仓库）
由于功能多且复杂，测试较多，运行很长。利用Cruise的并行化特点，每个团队将测试分成28组。一旦提交后，Cruise会将其放在28台机器上并行运行。运行后，将所有测试输出和结果上传到同一处（Cruise Server的中心仓库）。
益处：1. 反馈时间大幅度缩短（原来30分钟以上，现在20分钟之内）。
2. 易扩展：如果因测试增多而导致反馈周期长，可通过增加更多的机器解决。
3. 易维护：对于测试分组和构建机器的增减来说，在Cruise中都非常容易，只要在同一处修改配置即可。
4. 易追踪和Debug：所有的信息（包括artifacts）都放在同一处，能过Web访问。
5. Single view (在同一个Web管理页面上，可以监控所有团队的构建状态)。
第三步目标：减少手工操作方法：一键发布————自动化部署
手段：使用持续发布管理工具Cruise (Cruise的dependency + Story Tracker plugin + audit)
由于有很多个团队，每个团队都有多个测试环境。如果全部使用手工部署分花费很多时间。所以，每个团队建立三个构建管道，其目标分别为：(1)得到测试过的 installer；(2)部署到测试环境中；(3)将通过测试的installer部署到演示环境中。前一个构建成功后，就可以触发下一个（自动或手动）。
益处：1. QA可以清晰识别需要测试哪个安装包，该安装包中含有哪些功能
2. QA自己可能很容易地部署测试环境。
3. 易于追踪功能的历史版本(在同一个pipeline中，所有的stage同一版本.而且在使用Pipeline dependency时，版本信息会向下游传递)。
4. 易于掌握对各种部署环境的管理。

deploy1.jpg (71.7 KB, 下载次数: 2)
下载附件
2012-12-6 13:37 上传

使用上述手段后，该项目的持续交付已入佳境。目前可以做到：
所有的构建和部署都是自动化的；开发人员最多在20分钟内就会得到反馈。对于每种环境来说，可以做到每天部署四次。部署无差错：因为是自动化过程，每次的执行步骤都一样。机器资源复用：Cruise自动向165台机器上分发工作进行构建和部署。所有信息都显示在一个屏幕上（Single dashboard view of everything!）开发人员非常高兴：他们可以多次提交而不影响他人。测试人员非常高兴：他们可以很快地得到好的installer，通过自己点一下按钮就完成部署工作。管理人员非常高兴：他们可以马上了解当前的项目状态（哪些版本在测试中，那些版本已经演示了）。很容易了解每个版本里包括哪些功能和修复了哪些缺陷。

千问 · 2015-9-22 15:53:22

作者：乔梁
个人简介: 持续集成&持续交付领域先行者，敏捷&精益咨询师，致力于帮助企业提高软件交付能力，已为多个大型电信企业、互联网企业、移动设备制造商提供专业的软件交付咨询和培训服务。现任InfoQ特约编辑，主持《持续集成专栏》，译有《持续交付：发布可靠软件的系统方法》（该书获得2011年Jolt 杰出大奖），《ThoughtWorks 软件开发沉思录》。曾任Thoughtworks资深咨询师，百度项目管理部高级架构师。新浪微博：http://weibo.com/tony1130

文章出处：qiaoliang’s blog

千问 · 2015-9-22 15:53:22

目前所做的项目采用的就是持续集成！

千问 · 2015-9-22 15:53:22

good job