hudson项目中的运用

　　项目中持续集成管理一直是用的hudson，最近的话，hudson遇到不少问题，因为之前对这个也不是很熟悉，所以也花了比较多的时间去解决，现在刚好也可以总结下自己学习到的hudson知识。

　　首先在我看来，hudson只是一个持续集成的工具，在项目中，经常有开发直接告诉我们一个项目的svn目录地址就认为可以把包打好生成出来，这里的话如果只是普通的把源码从svn里检出来，不需要其他操作，是可以直接打成需要发布的包的，但是往往每个job都需要其他一些步骤才能生成包，这些命令就需要开发提供了。

　　说说我们项目中的运用吧，因为项目比较多，有很多不同的组，所以hudson需要建立的job也很多，目前每个job主要设置了几个流程。

• build

　　　　build就是不执行单元测试的脚本，只是简单的编译，如果编译通过就打成一个包，然后把包放到一个备用目录下面，放到备用目录下面的原因是如果有单元测试的话，就执行单元测试的job。

　　　　build的时候还有做的一步就是把版本号记录到一个log文件里面，同样提交到svn里面一个log目录。

• ut

　　　　ut就是执行单元测试脚本，当第一步build通过之后，就从备用目录下面把包拿过来，执行单元测试，如果单元测试通过，就把包放到运维可以拿到的目录下面，如果开发需要发布哪个版本，直接告诉运维版本号即可。

• cat

　　　　cat就是用来执行回归测试的job，并不是每个项目都会有回归测试，如果有的话，就和ut一样，其实相当于在单元测试的基础上所做的另外一步验证操作。

大致的流程就是这样，具体来说，比如一个job，Parser

那么分别有三个hudsonjob，Parser_build,Parser_Ut,Parser_Cat,然后svn的上有一个log目录，对应这个项目的三个job的日志文件，记录版本号。

　　当Parser_build执行完毕之后，更新了日志文件里面build的记录，Ut的job监控到该日志文件发生变化，就运行ut，然后从日志文件里面获取对应的代码版本号，从备用目录里面拿出来打好的包，然后执行单元测试。这里hudson可能可以设置两个job之间的运行关系，使得一个跑完就执行另外一个，但实际中没有采取hudson自带的设置，而是通过日志文件来联系不同的job，这样做是因为，我们可能一个Parser项目会依赖很多自己写的lib包，所以一个buildjob可能会监控多个svn目录，为了保持代码是最新的，我们会比较这几个目录的版本号，选出最大的当做本次job的版本号，然后记录到日志里面。

遇到的问题：

FAQ：

1.有的时候hudson同一个版本号会执行两边，或者版本提交后长时间没有触发job?

这个问题遇到了好几次，找了很多原因，发现是执行hudson机器和svn的机器时间不同步，当时间差超过了一定值，hudson就无法检测到svn里面有版本更新，或者会重复检测到更新，这里我也有疑问，hudson不是应该通过检测svn库里面版本号的变化来触发job吗？为什么会和时间有关系呢？我试过在本地把机器时间提前很多，然后svn log也可以发现svn版本的变化。Google很久，也有遇到类似问题的，同样是时间不同步引起，但是都没说明为什么。

2.配置文件一定要注意备份啊！！！

hudson方便之处，如果要换个环境做hudson服务器，只需要移植下每个job的配置文件即可。以前一直没有定时备份，后来有一次，内网hudson2.0升级到3.0的时候，发现升级了很久没好，就换回到2.0，查看配置文件，发现shell这些命令还在，就是svn目录地址这块配置信息不在了！！这个如果是每个job一个目录还好，偏偏有些job需要同时好几个目录，搞了很久，才弄好，现在都做了cronjob定时配置文件，还可以通过hudson的一个backup插件进行备份。所以备份一定要做，虽然hudson很安全，但是你永远不知道会发生什么问题。

3.hudson执行方式

hudson执行方式主要两个，简单一点就是nohuo java -jar ，另外就是tomcat,一开始用的是nohup，但是好像很不稳定,现在开发也会频繁访问hudson页面，加上本来job执行就多，于是这个java进程老挂掉，现在改成了tomcat下运行，貌似是流畅不少，tomcat下运行一个简单方法就是把webapp下面东西全部删除掉，把hudson.war放到下面，命名为ROOT.war即可。