JAVA持续集成解决方案
 
敏捷方法倡导java持续集成，并输送很多有用的工具。当前比较流行的持续集成服务工具有

1) apache continuum
2) CruiseControl
 
   配套做持续集成的工具包有
   1) JUnit 单元测试
   2) JUnitPerft或者eclipse tptp 做单元性能测试
   3) 数据库DDL初始化语句
   4) EasyMock 等模拟工具
   5) PMD，checkStyle,FindBug分析工具
   6）httpUnit HTTP接口测试
   7) purify/Jprofile 动态分析
   8) EMMA/Clover度量代码覆盖率
   9) JAVANCSS度量代码复杂度
   10) JDepend 度量耦合度
   10) 构建工具ant,
   11) 部署脚本
   12)分布式分发框架staf/stax
 -------------------------------------------------------------------------------------------- 

对持续集成的一点看法

持续集成，即Continuous Integration，以前叫daily build，其实是同一回事，它们主要的区别在于持续集成强调的是及时反馈以及集成频率。及时反馈是在构建或者测试用例失败后能快速的向开发人员提供反馈，同时其集成频率也要比daily build的更加频繁。那么什么是持续集成呢？我的看法是：持续集成是频繁的、持续的从源码服务器中check out 最新代码，进行自动编译，自动生成二进制代码，并运行针对现有代码的测试用例，并及时反馈结果。从以上定义看出持续集成需要有一个源码仓库来统一管理源代码，需要自动构建，比如用maven来自动构建，以及一个持续集成的工具，比如hudson。

      以前错误的认为持续集成只要编译通过就好，其实不然，还应包括一个重要的部分—–测试，通过运行更详尽的测试集可以大大提高持续集成的价值，因此会首选更详尽的测试。如何保证测试集的完备性，需要详细分析业务以及让测试脚本包含所有校验点。我在刚开始做topApi测试时，有时候为了赶进度，在测试接口时只是人肉观察数据库或者页面相关字段的变化，而没有用脚本实现校验点，这样是非常不好的，可能在测试的当时用例都是成功，逻辑也是正确，但如果后续服务端代码开发不小心改错了，或者相应接口后续要重构了，那到时候再来回归这些脚本的话，这些脚本其实是不可信的，很有可能会由于一些校验点没有用脚本实现而遗留bug，当然也就失去了持续集成中测试代码的价值。

        持续集成在topApi这边发挥了很大的作用。api接口调用了各业务方的接口，如果业务方改动相应接口或者进行版本升级，通过持续回归相应测试用例来保证对应接口的改动或者版本升级是否对top对外接口有影响，同时top这边也会有一些对现有接口新增需求，一般也通过回归测试用例来保证新增功能不会对接口原有功能有影响。因此，个人认为，持续集成的最大好处是能够让开发者充分相信自己修改代码不会对现有功能带来较大问题，更不会因为一些低级bug带来故障，当然，这必须保证现有测试集以及校验点的完备性。

        由于持续集成强调的频繁的集成，因此势必会有代码的维护成本和集成的时间成本。还是以topApi为例，目前api的测试用例有3000多个，回归商品接口的所有用例至少需要1个半小时，同时跟进分析报错的测试用例，也要花很多时间，这个时间人力成本还是很大的。但比起遗留bug到线上，我觉得这个成本还是很有必要投入的，毕竟鱼和熊掌不可兼得。