持续集成——保持项目节奏实践之一

第9章 保持项目节奏

项目经理不但要用管理实践掌控项目，还可以欢迎团队改变自己的技术实践，从而获得更大收益。本章包含的一系列实践，能为项目带来很多好处。项目经理和团队要根据自身的实际情况，判断如何调整、使用这些实践，而不要强制推行。如果你认为它们有所裨益，不妨将其介绍给团队，并欢迎团队积极尝试。

9.1 在项目中使用持续集成

开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。

持续集成可以让开发人员马上得到所做工作的反馈。他们开始考虑将大任务拆分成更小的部分（这可以让他们以更快的步伐前进），还能尽早识别出项目的集成风险。持续集成让开发人员每天都能有所收获，帮助项目团队找到符合自己的节奏。

开发人员只有在完成了某个功能的代码后才将其签入，这就是按阶段集成的方式。有些开发人员一周签入一次代码。有些更糟糕的项目，开发人员一到两个月才签入一次代码。按阶段集成会打断项目的节奏。构建时出现的问题，会中断设计和编写新功能代码的人们的思路。他们不得不记住很多小细节，而这些小细节覆盖了从项目开始直到进行集成的各个阶段。如果忘记了这些细节，项目进度会放缓，因为团队发现了缺陷，而且必须想起可能是几个月前所写代码的细枝末节。这其实是一种同时处理多任务的方式，而且特别不容易发现。人们是在做同一个项目的工作，而且手上的任务可能也相关，但是思考问题时的抽象层次却有所不同（设计比调试的抽象层次更高），而且也不再是处理同一个功能的问题，思考问题的上下文由此发生了变化。所有切换上下文的代价都发生在这里（参见16.7.3节），在设计下一个功能时，开发人员可能会因此而丧失好的想法，还可能增加向设计中引入缺陷的潜在风险。

频繁构建是为开发人员和项目经理准备的

如果你提出使用每日构建，测试人员可能会抱怨：“我们做不到以如此快的速度构建，只能每周构建一次。”频繁构建，比如每小时甚或每天，不是为测试人员准备的。频繁构建可以为开发人员提供反馈，同时让项目经理了解项目状态。

如果测试人员可以利用每日构建来运行测试，那就太棒了。不过即使测试人员做不到这一点，通过每天构建可工作的代码，并维持这样的节奏，开发人员也可以从中获得有价值的反馈。

如果项目经理不能将变更后的代码集成到代码库中，你可以采取持续集成的变种。假设你管理一个项目团队，大家的任务是扩展一个已存在产品的设计。团队目前正在处理的部分产品代码是整个产品的基础。如果这部分代码无法运行，那整个产品都不能运行。你现在不想签入代码，因为这样会破坏现有的产品，而且会占用三个月的时间来添加和替换产品的现有功能。你该怎么做？

应该选择现有状况下的最佳方案。你可以将主代码库做一个分支版本，并让所有开发人员在这个分支版本上开发。他们每次签入一些代码，都会与主线代码进行同步，保证自己的分支代码是最新版本。这使得开发人员总是在最新和最全的代码版本库上进行开发，而且他们一直都在进行集成。当他们完成各自工作后，就会将所有代码都合并回主线。

这是持续集成的一个变种。如果必须重写已经存在的代码，而且在开发变更代码时不想破坏现有系统，可以采用这种方式。如果项目经理管理的项目所提供的服务要为一组产品使用，比如一个程序库或是一个平台，这种方式同样适用。

---

见http://www.martinfowler.com/articles/continuousIntegration.html。