持续集成小记

CI是持续集成Continuous integration的缩写。 

这个概念最早是我在PRT实习培训的时候听说的，主要介绍了持续集成的概念和工具Mercurial，但当时没有非常深入的理解它的重要性，只觉得搭建环境非常麻烦，当时还有一个Build Master的职位，可惜我没有申请。 

现在在HW加入集成测试组，小组主要工作都在围绕着CI。对CI又有了重新的认识。 

持续集成，是在一定周期内，反复构建，自动验证，甚至自动发布项目的方法。

是敏捷开发中的一条敏捷原则，敏捷开发鼓励尽可能多的集成测试。当然，最小周期是每次代码提交，因为如果代码库中没有变化，那重复集成测试是没有意义的， 

HW公司用的ICP-CI软件，一套环境由一个CI-master和多个CI-Agent（1个甚至没有也可以）组成，前者主要主导CI，可以跑正在集成测试多个项目，Agent只是分担某项目构建的工作量而已。 

当我们需要对某项目进行集成测试的时候，比如报表系统，我们先通过SCP在CI-master所在的服务器上创建工程路径，然后再打开浏览器，访问CI-MASTER管理界面(BS的一个管理系统，主要CI工程的操作都在这上面进行)，创建一个新的工程。当指定完工程在服务器上的路径，以及配置一些环境变量之后，我们即可开始写CI流程。 

其他工程的流程我不太了解，我的报表系统（Web工程的CI流程大体上差不多是这样的吧）是这样的：先是从SVN上将项目更新下来，然后进行静态检查，然后编译，然后再进行编译后的检查，通过所有检查之后，系统将自动打成一个war包，并发布到指定的服务器路径，并重启服务器。 

编译打包的部分可以试用Ant脚本来实现，检查的部分，主要是由一些已有的工具完成的，只需填写一些配置信息，而其他自动部署的操作，远程连接操作，或其他特殊的需求，可以自己写Shell脚本，Bat脚本，等，然后让CI在某一情况下自动调用。 

这里说一下Tomcat的自动部署，在我的工程中，全部检查完毕后，需要将war包拷贝到另一台机器，并重启该机器上的tomcat服务器。我们是这样实现的，先用ant脚本打包，然后master通过ssh方式关掉远程的tomcat，把另一个clear.sh脚本（包含备份和清理被替换工程的shell脚本）SCP到远程，然后又远程调用这个脚本，使其在本地就完成了一系列操作，之后再远程把Tomcat启动起来。