在上篇中,介绍了per-commit的workflow的实现方式。在这篇中将要介绍在此基础上的smart build,以缩短整个流程,提升效率。
在实际的项目中,涉及到多个solution的build, 有product的,有test的,也有tool的。
solution之间又有一定的依赖性,比如说某个tool的代码改动,需要重新编译product, test 。product代码的改动,需要编译test solution。
为了解决整个问题,首先要做的是根据各solution之间的依赖性,定义出整个build的workflow,比如哪个solution的改动,除了build自身外,还需要重新build哪些其它的solution,
只要能清晰的定义出这个workflow,不管是用c++/java 或者脚本实现都是比较容易的。
这个smart build solution需要一个传入的参数,那就是对应的这个commit的change log文件,在这个change log文件中,详细的描述了哪个目录中的哪个文件进行了改动。只要遍历该文件,就可以得到哪些solution被改动的信息(每个solution在SVN中都有固定的文件目录结构)。
有多重方式可以获得该change log文件,1) 可以通过svnkit,以给定的revision编程得到; 2)可以通过jenkins的REST API查询得到,比如:curl -s "%JENKINS_URL%job/%JOB_NAME%/%BUILD_NUMBER%/api/xml?wrapper=changes&xpath=//path//file" > changelist.txt
然后,就是结合Samba服务器实现整个workflow,在Samba中创建一个共享目录,在上面保存所有solution的最新的output,当在smart build solution中需要编译某个solution时,更新在Samba上的对应的output, 如果不需要编译某个项目时,把Samba上保存的对应的output拷贝到本地对应的文件目录中。
当所有solution编译完成时,可以成功的实现打包操作。
通过这种方式,按照概率统计,在目前的项目中,可以把整个编译的时间节省到原先的一半。