2012 年 7、8 月份，我们逐渐了解了持续集成的概念，同时我们家庭作坊的dailybuild方式不断爆出各种问题，并且已经无法满足日益增长的各种需求。
我们开始探索持续集成的不同实现方式，首先我们关注业界非常流行的持续集成平台：
|
持续集成平台无非包含如下几个方面功能：
1、流程（一个代码下载、编译、代码检查等工作的过程我们称之为流程）调度
2、各种代码检查工具以及命令的支持
3、结果消息推送
4、流程执行信息展示
5、其他
使用hudson，初步的把我们一个工程的所有功能点都配置完成，说一说hudson配置过程的感受：
1、hudson 的安装和启动非常方便
2、流程配置可以界面话，但是界面不是很友好（插一句，hudson的插件模式还很方便的，正常来说如果你有时间也可以通过开发一个配置界面的插件来满足自己的配置需要）
3、流程的建立主要还是ant 或maven 脚本、批处理脚本以及shell 脚本的编写，通过hudson平台来串联
4、hudson 权限管理已经存在，可以根据不同的用户赋值不同的权限。
5、hudson 一个流程中执行单元的并发执行以及跨主机配置非常的不方便。
6、hudson 邮件推送可以自定义邮件模板，根据hudson提供的一些公共属性获取对应的内容，这方面设计的很不错，但是针对流程不易让对应的相关人员主动订阅
7、hudson 的执行单元执行结果不易分析入库
针对我们公司的一些实际需求，持续集成平台不仅将来需要这些功能，同时还必须可以和我们公司内部一些其他平台能够深度的集成，对于结果展示我们的个性化定制需求也非常的多。
前期我们考虑只需一个调度平台、展示以及推送的功能既可，同时考虑到后期的扩展，经过各种权衡，可能hudson的学习以及各种插件开发比我们自己开发一套持续集成平台成本更加的高，最终我们决定建设自己的持续集成平台。