随着越来越多的项目加入到持续构建服务器中，开发人员越来越频繁地提交代码，紧缺的构建服务器资源无法满足广大人民群众日益增长的构建需求。幸好Jenkins支持分布式构建，能够无缝地将一个构建任务分发到另外一台机器上执行，从而在一定程度上实现“云构建”。本文探讨在Jenkins中实现云构建的一些想法和实践，其他的持续集成服务器也是类似的。
什么是云构建？
以我对云计算浅薄的理解，所谓云计算就是N多机器放在一起，计算任务可以分配到云里面的任何一台机器上。同理，云构建就是N多机器放在一起，构建任务可以分配到云里面的任何一台机器上。这就要求构建服务器和构建任务标准化，使得对构建服务器而言，任何构建任务都是一样的；反之，对任何构建任务而言，任何构建服务器都是一样的。这样，当构建服务器资源不够时，只要往云里面添加标准的构建服务器就能承担更多构建任务。
如何实现？
在这个思路的指导下，那如何在Jenkins下实现构建服务器和构建任务的标准化。首先来分析一下Jenkins执行构建任务都做了什么。
- 将源代码从SCM（源代码管理工具，比如CVS，SVN，ClearCase等）里面签出（Checkout）出来；
- 然后，执行预先定义好的一些构建步骤（Build Step），比如编译、单元测试、静态代码分析；
在步骤1中，Jenkins依赖于：
- SCM客户端程序
- 源代码的地址
这样，Jenkins才能把源代码从SCM中签出。Jenkins内置了某些SCM的客户端程序（比如SVN）。某些SCM的客户端程序需要预先安装在构建服务器上，比如ClearCase。因此，为了标准化构建服务器，必须在构建服务器上预先安装Jenkins中没有内置的SCM客户端，比如ClearCase，CVS等。
在步骤2中， Jenkins可能依赖于：
- 执行构建步骤的程序，比如Ant，Maven，JRE，Visual Studio等；
- 第三方库，比如Java单元测试框架JUnit，代码覆盖率检查工具Cobertura等；
- 构建脚本，比如Ant的build.xml；
- 环境变量，比如某些脚本会需要JAVA_HOME，ANT_HOME等环境变量。
为了简化构建服务器的配置，应当尽量避免在构建服务器上做过多的配置，理论上构建服务器只要能够把代码签出来，执行一条构建命令就能开始构建。只要做到了这一点，构建任务就可以认为是一个标准的任务，任何构建服务器都能构建这个任务。这样的好处是，当构建配置需要更改，只需修改一个地方并将其提交到代码库中，所有的构建服务器都自动获得这些变化，而不用在所有的构建服务器上做更改。
为了能够做到这一点，我们的思路是尽量把构建任务中变化的东西都放到SCM中，这里有一些我们团队采用的方法：
- 尽量把依赖的工具和库放到SCM中，比如Ant，JRE，Maven，Junit等第三方工具和库。这样只要把代码库签出来，构建服务器上就有正确的构建工具和库，避免了不同的机器上因采用了不同版本的构建工具或者库导致的问题。
- 尽量在构建脚本里面设置环境变量。像ANT_HOME, JAVA_HOME这样的环境变量应该执行从SCM签出的那个版本。
- 使用相对路径。
- 不要假设签出的代码会放到特定的目录层次结构中。比如，在ClearCase中，通常创建了DynamicView后代码就放到了这个View对应盘符的根目录中，但是在SnapshotView中， 代码就可能在一个比较深的目录层次结构中。在编写构建脚本时就需要考虑这种情况。
现在，对你的构建任务进行分析，看看哪些东西可以放到SCM和构建脚本中，哪些东西必须事先在构建服务器上做配置。如果你在用虚拟机做构建服务器的话，就可以把这些需要在构建服务器中配置的内容配到虚拟机的模板中。以后当构建服务器不给力的时候，只需从虚拟机模板中克隆一台新的虚拟机，然后将其加入到Jenkins的构建网络中(参见这里如何将新的机器加入到Jenkins的构建网络中)，轻松实现“云构建”。
小结
本文介绍了在Jenkins中动态扩展构建能力的实践经验，主要思路是将构建服务器和构建任务标准化，尽量不在构建服务器上保存任何配置，而将配置放到SCM中，从而能够轻松往构建网络中添加新的机器以提高构建能力。