全面分析持续集成优缺点(4)

我们发现很多开发者都经常看看这个页面，因为它让他们看到项目发展的方向，看到随着人们不断归还代码而发生的变化。有时我们也会在这个页面上放一些其他的项目新闻，但是需要把握好尺度。

　　要让开发者能在自己的本地机器上模拟主创建过程，这是很重要的。这样，如果集成错误出现了，开发者可以在自己的机器上研究、调试，而不必真的执行主创建过程。而且，开发者也可以在归还代码之前先在本地执行创建，从而降低了主创建失败的可能性。

　　这里有一个比较重要的问题：主创建应该是干净的创建（完全从源代码开始）还是增量创建？增量创建会快得多，但是也增大了引入错误的风险，因为有些部分是没有编译的。而且我们还有无法重新创建的风险。我们的创建速度相当快（20万行代码约15分钟），所以我们乐于每次都做干净的创建。但是，有些团队喜欢在大多数时候做增量创建，但是当那些奇怪的问题突然出现时，也经常性地做干净的创建（至少每天一次）。





图1：运行在投石车上的servlet

代码归还（Check in）

　　使用自动化创建就意味着开发者应该遵循某种节奏来开发软件，最重要的就是他们应该经常集成。我们曾经见过一些组织，他们也做日创建，但是其中的开发者却不经常归还代码。如果开发者几周才归还一次代码，那么日创建又有什么意义呢？我们遵循的原则是：每个开发者至少每天要归还一次代码。

　　在开始新的任务之前，开发者应该首先与配置管理系统同步。也就是说，他们应该首先更新本地机器上的源代码。在旧的代码基础上编写代码，这只会带来麻烦和混乱。

　　然后，开发者要随时保持文件的更新。开发者可以在一段任务完成之后将代码集成到整个系统中，也可以在任务的中途集成，但是在集成的时候必须保证所有的测试都能通过。 [Page]

　　集成的第一步是要再次使开发者的本地文件与代码仓库同步。代码仓库中所有新近有改动的文件都要拷贝到开发者的工作目录中来，当文件发生冲突时，配置管理系统会向开发者提出警告。然后，开发者需要对同步后的工作集进行创建，对这些文件运行BVT，并得到正确的结果。

　　现在，开发者可以把新的文件提交到代码仓库中。提交完成之后，开发者就需要等待主创建。如果主创建成功，那么这次归还也是成功的。如果主创建失败了，开发者可以在本地修改。如果修改很简单，就可以直接提交；如果修改比较复杂，开发者就需要放弃这次修改，重新同步自己的工作目录，然后继续在本地开发、调试，然后再次提交。

　　某些系统强制要求归还进程逐个进行。在这种情况下，系统中会有一个创建令牌，同一时间只有一个开发者能拿到令牌。开发者获取创建令牌，再次同步文件，提交修改，然后释放令牌。这就确保创建过程中，最多只能有一个开发者在更新代码仓库。不过我们发现，即使没有创建令牌，我们也很少遇到麻烦，所以我们也不用这种方法。经常会有多个人同时向同一个主创建提交代码的情况，但是这很少造成创建失败，而且这样的错误也很容易修复。

　　同时，我们还让开发者自己来决定归还过程中的小心程度。这反映出开发者对集成错误出现几率的评估。如果她觉得很有可能出现集成错误，那么她就会在归还之前先做一次本地创建；如果她觉得根本不可能出现集成错误，那么她可以直接归还。如果犯了错误，在主创建运行时她立刻就会发现，然后她就必须放弃自己的修改，找到出错的地方。如果错误很容易发现、很容易修补，那么这种错误也是可以接受的。

总结

　　发展一个制度严密的自动化创建过程对于项目的控制是很重要的。许多软件先贤都这样说，但是我们发现，这样的过程在软件开发领域中仍然罕见。

　　关键是要让所有的事情都完全自动化，并且要经常进行集成，这样才能尽快发现错误。然后，人们可以随时修改需要修改的东西，因为他们知道：如果他们做的修改引起了集成错误，那也是很容易发现和修补的。一旦获得了这些利益，你会发现自己再也无法放下它们。