持续集成通过自动化构建、自动化测试以及自动化部署加上较高的集成频率保证了开发系统中的问题能迅速被发现和修复，降低了集成失败的风险，使得系统在开发中始终保持在一个稳定健康的集成状态。jenkins是目前广泛应用的持续集成工具，本文记录我使用jenkins+Git配置持续集成环境的整个流程以及踩到的坑（jenkins过程的坑往往不是在第一次配置，而是在配置结束后更改某些配置项的时候踩到）。

总体流程如下：

下载完毕后，将jenkins.war丢入tomcat/webapps目录下。

默认情况下，jenkins的工作空间会放到C:\Users\Account\.jenkins目录下，，如过想要更改工作空间，我们需要在系统环境变量里面配置JENKINS_HOME变量，将该变量指向目标工作空间。这里需要注意的是，tomcat启动情况下，jenkins不会去读JENKINS_HOME变量，必须要重启tomcat。而重启tomcat也是有坑的，如果tomcat是通过命令行执行tomcat/bin/startup.bat目录启动的，那么单单停掉tomcat没用，必须要将前面提到的命令行一并关闭掉，这时重启tomcat，jenkins才会使用JENKINS_HOME中配置的目录作为工作空间。此外，一旦更换工作空间，此前过于jenkins的所有配置都将作废。

我们的产品使用Git作为版本管理工具，而jenkins需要git插件来支持git，所以我们需要为jenkins添加git插件。

在Available tab页中找到Git Plugin

点击下方的Install without Restart安装插件。

插件安装完毕后，我们需要在jenkins中配置Git.exe的位置。

点击保存，jenkins整体的配置可以告一段落，下面我们来创建和配置job。

点击左侧的New Item，选择一个自由风格的job，点击OK。

在源码管理工具（Source Code Management）中选择Git，添加Git仓库、添加Git证书、选择一个分支：

关于证书我们选择，SSH形式：

这个key跟我们在gitHub中配置公有秘钥的道理是一样的，jenkins调用git命令去Git服务器上pull代码，git服务器通过检查公钥私钥来保证安全性。如果机器上没有git的ssh key需要自己动手生成一个。

如果Git仓库有子仓库，我们需要对子仓库进行配置，这里选中循环更新所有子仓库：

持续集成的目的不是简单的将源码下载下来，而是通过持续集成进行单元测试、自动化测试、自动构建发布。所以在源码下载完毕后需要执行的命令可以放到Buid部分：

这里我们使用bat命令:

cd %workspace%\client\buildScripts\
build.bat
cd "yourPath"\buildOutput
xcopy stem \\NAO\webapp /Y /E

上面命令的意思是：

进入buildScripts目录，%workspace%是jenkins提供的环境变量，指向我们job的工作空间，强烈建议使用该环境变量。

执行build.bat命令，build.bat中调用其他命令执行build脚本。

进入buildOutput目录

将buildOutput中的stem下所有内容拷贝到NAO机器的共享目录中。

点击保存，进入到我们刚刚创建的job的控制界面中，点击Build Now，便可以开始我们的持续集成的旅途了。

点击某一次具体的构建，我们可以查看日志输出：

注意这里的构建并不检查build.bat中的错误和输出，换句话说如果build.bat失败，本次构建过程不会失败。解决方法是使用jenkins的Log Parser插件，同使用Git Plugin一样，在插件管理中找 Log Parser插件，并添加。添加完毕后，配置jenkins中的Console Output Parsing

rule的具体规则语法可以使用正则表达式，具体可以参考Log Parser插件的文档
http://my.oschina.net/donhui/blog/382592

Parsing Rules File的配置同上文的配置工作目录具有一样的坑，如果要更新规则，首先要清除job中选中的规则，然后删除此处配置的Parseing Rule，重启tomcat。

添加完毕后，在job的配置页的 Post-Build Actions部分选中Console Output parsing

然后进行如下配置：

这样我们可以对buld.bat中的error进行捕获，并且在某次构建过程的Parsed Console Output中进行查看