Jenkins，是从Hudson fork出的一个开发分支，因与Oracle Hudson商标纠纷改名为Jenkins（详见），Jenkins是基于Java开发的一种持续集成工具，用于监控秩序重复的工作，包括：软件版本发布/测试的持续集成、外部调用执行工作的监控等。
1、 Jenkins 下载
Jenkins 下载网址： Download Jenkins
Jenkins 最新版本： jenkins_1.514_all.deb（Ubuntu/Debian）， 或 jenkins.war（war包）
2、 Jenkins 安装
（1） 安装Tomcat， 请见我先前的博客： Ubuntu 配置 Tomcat
（2） 安装Maven，请见我先前的博客： Linux 搭建 maven
（3） 拷贝下载的 jenkins.war 到 tomcat的webapps目录下：
sudo cp jenkins.war /opt/apache-tomcat-7.0.40/webapps/
3、 Jenkins 配置
（1） 打开/etp/profile配置文件， 配置maven的工作目录： sudo vi /etc/profile
（2） 添加maven工作目录： export JENKINS_HOME=/opt/apache-tomcat-7.0.40/webapps/jenkins 如下：
（3） 使/etc/profile配置文件生效： source /etc/profile
4、 Jenkins 验证
在浏览器里，输入网址： http://localhost:8080/jenkins/ 显示下面界面：
出现上图界面，表示安装成功！
注： Android工程持续集成的自动化构建（ant + jenkins + svn/git），在后面会奉上，敬请关注本博客 ^_^
参考推荐：
Jenkins（官方）
Hudson（官方）
Installing Jenkins on Ubuntu
Jenkins服务器安装与配置
Jenkins "Hello World"
Spring链接：
http://s3.amazonaws.com/dist.springframework.org/release/SPR/spring-framework-3.0.5.RELEASE.zip
下载完毕后，解压缩到合适的目录，推荐放到eclipse目录的plugin中。
导入有两种方法，推荐方法一。
方法一：
Preferences->Java->Build Path->User Libraries中
- New一个User Library，命名为spring
- Add JARs，将之前解压出的JAR包添加到spring中
- 点击OK，确定
- 左键项目名->Properties
Java Build Path->Add Library->User Library->Next
选中之前添加好的User Library，Finish
于是Spring库导入成功
方法二：
直接将Spring库文件导入到项目的Java Build Path属性中。
将Spring库导入之后运行Spring测试程序发现报错：
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:160)
at org.springframework.context.support.AbstractRefreshableApplicationContext.<init>(AbstractRefreshableApplicationContext.java:89)
at org.springframework.context.support.AbstractRefreshableConfigApplicationContext.<init>(AbstractRefreshableConfigApplicationContext.java:59)
at org.springframework.context.support.AbstractXmlApplicationContext.<init>(AbstractXmlApplicationContext.java:61)
at org.springframework.context.support.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:137)
at org.springframework.context.support.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:84)
at erictest.EricTest.main(EricTest.java:8)
发现是缺少Spring依赖的commons-logging库
commons-logging库：http://commons.apache.org/logging/download_logging.cgi
用同样的方法导入commons-logging之后程序即可正确运行。
撒花！
eclipse加载struts2时类似。
参考http://www.cnblogs.com/ericsun/archive/2011/07/11/2103504.html
基于server的请求回放领域，一般分为离线回放和在线实时复制两大领域，一般研究者都是从离线回放的角度在苦苦研究，而在实时复制领域，研究非常少，至少从sigcomm评审人的评审意见来看，没有看到相关内容。
请求实时复制，据我所知，一般可以分为两类：
1）基于应用层的请求复制2）基于底层数据包的请求复制
传统的做法一般从应用层面进行复制，比如基于服务器的请求复制，这种复制的好处就是实现起来相对简单，但也存在着若干缺点：
1）请求复制从应用层出发，穿透整个协议栈，这样就容易挤占应用的资源，比如宝贵的连接资源
2）测试跟实际应用耦合在一起，容易导致对在线系统的影响，比如有些基于服务器的复制，会导致用户请求的处理时间取决于最慢的请求处理时间（max(真正的请求处理时间，被复制的请求请求处理时间））
3）很难支撑压力大的请求复制（据若干用户反映，这种类型的请求复制，曾经严重影响在线系统）
基于底层数据包的请求复制，可以做到无需穿透整个协议栈，路程最短的，可以从数据链路层抓请求包，从数据链路层发包，路程一般的，可以在IP层抓请求包，从IP层发出去，不管怎么走，只要不走TCP，对在线的影响就会小得多。
因此从数据包的角度去做基于server的请求复制，方向是对的，而且潜力非常巨大，很可惜，tcpreplay的作者做了一点这方面的探索（flowreplay），就放弃了。这方面的研究至少我没有看到过（一般都去研究整个网络了，sigcomm评审人也没有提出类似的研究方案）。
进入正题，tcpcopy是如何进行架构演化的呢？
由于tcp交互是相互的，一般情况下需要知道服务器的响应数据包信息，才能利用在线请求数据包，构造出适合测试服务器的请求数据包，
因此只要基于数据包的方式，无论怎么实现（除非是tcp协议改的面目全非），都需要返回响应包信息。
三种架构的差别就在于在什么地方截获响应包
我们先看看tcpcopy最初的架构：
从上图可以看出，tcpcopy是从数据链路层抓请求数据包，发包是从IP层发出去，测试服务器的TCP协议栈没有类似ip queue或者nfqueue的干扰，响应包会直接返回给在线机器（通过设置路由），tcpcopy可以在数据链路层捕获到这些响应包，这些响应包会到达IP层，一般最终被丢弃掉（除非是客户端IP地址就是这台在线机器的IP地址，会通过IP层，但会被TCP reset掉）。
这里要特别感谢tcpcopy鼻祖王波同学（@wbo65），是他在这方面进行了最初探索。
（2009年设计并代码实现，仅仅300多行代码就支撑了网易广告投放系统的最初开发（上线零失误，解决上线前数百个问题）,当然这个最简单的版本应用范围非常有限，本人也在2010年末在这个架构上面进行了深度改造，扩展到1000多行代码，因此对tcp协议有了最初的认识）。
回到正题，这种架构一般只能工作在同一网段，而且对于外网应用，一般只能复制单台在线流量给测试服务器，无法对网易广告投放系统进行深度问题发现和潜能挖掘。
第一种架构总结如下：
好处：
1）简单，粗暴
2）适合冒烟测试
3）对测试比较真实
不好的地方：
1）相对而言，会更加影响在线，因为响应包信息全部回给在线机器了（当然这种还是比应用层面的请求复制，影响更小）
2）同一网段限制
3）对于外网应用，无法充分利用或者很难充分利用多台在线流量，从而无法为压力测试提供技术支持
4）内网应用严重受限制，因请求的客户端ip地址不能是被复制的在线机器的ip地址
第二种架构，也就是目前开源的架构，设计也是tcpcopy鼻祖王波同学设计（2010年设计出来，2011.6月设计移交给多人,包括我），大致架构如下：
从上面图中我们可以看出，tcpcopy默认从IP层抓包，从IP层发包，与第一种架构不同的是，我们在测试服务器进行响应包的截获，并通过intercept程序返回响应包信息给tcpcopy。这种架构为分布式压力测试提供了可能性，相比第一种架构，大大推动了tcpcopy的进化。
我们先从响应包的截获来分析，理论上，可以在测试服务器的IP层或者数据链路层进行截获响应包，我们具体分析如下：
1）在数据链路层抓，正常情况下，其响应数据包会返回给真正发起请求的客户端，这会或多或少影响到客户端的TCP（频繁地reset）模块，而且在压力大的时候，会给交换机、路由器甚至整个网络，带来不必要的干扰。
2）在测试服务器的IP抓响应包，正好有netlink技术来解决上面的问题，netlink是一种用户态进程与内核进行交互的技术，具体地我们可以利用内核模块ip queue（内核3.5以下版本）或者nfqueue（内核3.5或者以上版本）来达到捕获响应包的目的。
我们采用了第二种方式，也即上图中的IP层来截获响应包，当响应包传递给intercept后，我们就能copy到响应包信息，传递给tcpcopy，我们还可以通过verdict告诉内核，该如何处理这些响应包，如果没有设置白名单的话，就会在IP层丢弃掉这些响应包，这时候你是无法利用tcpudmp来抓到这些响应包的（tcpdump工作在数据链路层）。
这种设计的好处就是可以支持复制多台在线流量到一台测试服务器中去，我们在intercept保留路由信息，知道响应包该如何返回给哪一个tcpcopy实例。然而这种架构，intercept会不同程度地占用测试服务器的资源，而且ip queue或者nfqueue，并不一定能够高效工作，因而给测试，特别是高压测试和短连接压力测试，带来了很大麻烦。
这种架构总结如下：
好处：
1）支持复制多台在线流量
2）影响在线机器更小
不好的地方：
1）较第一种更为复杂
2）性能极限往往在ip queue或者nfqueue
3）intercept扩展性不好，受制于ip queue和nfqueue无法支持多进程进行响应包的捕获操作
4）intercept影响测试服务器的最终测试结果，特别是压力大的时候
5）无法对测试服务器进行完整测试（没有覆盖到数据链路层的出口）
上述架构，也即最新架构，是为了极限测试的目的而设计的，把intercept的工作从测试服务器（test server 1）中offload出来，放到另外一台独立的测试服务器（test server 2）上面进行截获，而且把原先从IP层捕获响应数据包的工作转移到从数据链路层抓响应包，这些改变大大降低了对测试机器的各种干扰（除了路由设置，其它已经没有影响了），而且大大扩大了捕获响应包的能力。当然这种测试也更加真实。
具体如下：
在运行上层服务的测试服务器test server 1上面设置路由信息，把待测试应用的需要被捕获的响应数据包信息路由到第二台测试机器test server 2上面，在测试机器test server 2上面，我们在数据链路层截获到响应包，再返回给相应的tcpcopy。为了高效使用，这种架构推荐使用pcap进行抓包，这样就可以在内核态进行过滤，否则只能在用户态进行包的过滤，而且在intercept端或者tcpcopy端设置filter（通过-F参数，类似tcpdump的filter），达到多个实例来共同完成抓包的工作，这样可扩展性就更强，适合于超级高并发的场合。
总结如下：
好处：
1）更加真实
2）可扩展性更强
3）适合高并发场合
4）无ip queue或者nfqueue的各种限制
5）对测试服务器几乎没有任何性能干扰的影响
6）在运行服务的测试服务器，运维更加方便
不好的地方：
1）操作难度更大
2）需要的机器数量更多
3）需要的知识也更多
上面三种架构均具有价值，目前开源出来的仅仅包括第二种架构和第三种架构，tcpcopy默认采用第二种架构，有条件的可以采用第三种架构。
对于如何采用新架构，参考http://blog.csdn.net/wangbin579/article/details/8950282
最后，对于请求复制，要想达到对在线没有影响或者影响尽可能小，可以采用如下对策：
利用高性能的旁路机制，复制请求数据包到另外一个