在使用持续集成之前,很多开发团队都使用每日构建(nightly build)。当时,微软使用这个实践已经很多年了。谁破坏了构建,就要负责监视后续的构建过程,直至发现下一个破坏了构建的人。

现在很多项目仍旧在使用每日构建的做法,在每天晚上,所有人都回家以后,通过批处理过程对代码库进行编译集成,这么做的确有一定的益处。但是,假如第二天早上,团队发现代码根本无法编译成功,这显然就没有太大的帮助了。因为第二天团队还是会向代码库中再提交新的修改,可直到第二天晚上才能再次验证这个系统是否能够集成起来。久而久之,构建就天天都是红色的 了,而这种失败状态很可能会延续到最后的集成时间点才会被修复。另外,当团队不在同一地点办公,而且是人员分散在不同的时区里,同时还使用同一个代码库时,这种做法基本上就没有什么用了。

接下来具有革命性的一步是增加自动化测试。我们首次尝试自动化测试是在很多年以前。毫无疑问,那时候都是最基本的冒烟测试,简单地断言应用程序可以运行汇编。在当时,这是构建过程中我们引以为豪的非常大的一个进步。可是现在,即使是最基本的自动化构建过程也比那时的功能强大。单元测试已经流行有一段时间了,简单的单元测试套件都可以为我们做构建提供更高的信心。

接下来,在过去某些项目中还出现过一种改进了的方式(坦白地说,我们近期没有看到过这么做的项目),即“rolling builds”过程,即持续不断地运行构建过程,而不是在夜间定时执行批处理过程。每当前一个构建完成之后,就立即从版本控制库中取得最新版本,进行下一次构建。在20世纪90年代初期,Dave使用过这种方式,取得了良好的效果。这种方式要比夜间构建好得多。但这种方式的问题在于,某次具体的提交与某次构建之间没有直接关联性。因此,尽管对开发人员来说,这样可以建立快速反馈环,然而很难追踪到是哪次提交令构建失败的,这在大型团队中尤其如此。

--摘自《持续交付》