“大”项目的关键是集成

一个朋友提到，他们的公司将clear case换成了git。而他的感觉是，由于git是分布式版本控制系统（DVCS），所以在几百人的分布式大项目中，如果弄不好，很快就会乱套。虽然有一个“主代码库”，但是可以想象，提交时的冲突会很多。

确实，Clear Case有很多先进的特征，我也很喜欢，除了它的价钱之外。但我认为，这里问题的关键是集成。

几百个人的分布式大项目，要让所有人的工作能够顺利集成在一起是一件不容易的事情。其中的难度早有定论：这些人需要沟通协作，而沟通时的不一致和冲突将耗费大量的时间和精力。所以，在大项目中，我们常常看到集成的工作量比编码的工作量要大，有时候甚至大得多。

开发人员多是一种类型的“大”项目，另一种类型的“大”项目是小团队，但复用了很多第三方的软件。这种类型的项目在开源软件中相当常见，比如Liferay就是一个例子。它使用了Velocity模板框架，提供与多种应用服务器的绑定，支持多种关系数据库后端，还支持第三方的CMS和用户管理。

这两种大项目，如何来实现集成？

据我所知，以前某些大公司的做法是，项目设置build manager或build team，专门负责集成构建。这样做的含义很清楚：集成工作量很大，我们要专派人手。

但现在业界的最佳实践是持续集成。

对于开发人员很多的项目，《持续集成》中介绍的一种集成方式或许可以解决他们的问题。设置两个Repositry，大家向第一个Repositry提交，如果提交后5分钟没有新的提交，就第一个Repositry上持续集成。如果集成失败，自动回退到上一次成功集成的状态；如果集成成功，将新提交的内容再提交到第二个Repositry。开发人员将在持续集成服务器上，看到自己的提交是否成功集成。也会在集成失败时收到通知。

（这个故事再次告诉我们：工具的价值小于过程的价值，过程的价值小于人的价值。人是改进过程和工具的决定因素。）

对于小团队大量复用的项目，持续集成仍是成败的关键。你可以在Liferay项目中看到大量使用Selenium自动化集成测试。

最近我独自一人开发程序时，也明显感到持续集成的重要性：我需要把一周、两周、一月、两月的工作集成在一起。也许，集成一直都比编码更重要吧。