持续集成 编年史 之 持续集成探索---平台选择

首先，我们需要调研一下：

1、使用脚本的自动化实现方式真的无法满足我们的需求吗？

2、为什么需要一个持续集成平台？

3、平台的实现方式比脚本优越性体现在哪里？

对于我们：

1、我们的业务非常复杂，待持续集成的版本非常之多，使用脚本自动化进行构建的不易进行统一管理，亟待一个平台来统一管理持续集成相关事宜。

2、dailybuild 形式爆出了各种问题，并且脚本的实现方式不易维护和扩展

3、为了能快速的推广持续集成这个理念，需简化持续集成流程配置的复杂度，降低构建的门槛

最终我们决定使用持续集成的平台来推官持续集成工作，首先我们关注业界非常流行的持续集成平台：

CruiseControl (http://cruisecontrol.sourceforge.net/) Hudson (https://hudson.dev.java.net/) LuntBuild (http://luntbuild.javaforge.com/) TeamCity (http://www.jetbrains.com/teamcity/) AntHill Pro (http://www.anthillpro.com/) Bamboo (http://www.atlassian.com/software/bamboo/) QuickBuild (http://www.pmease.com/)

根据我们的需求和每种持续集成平台的特点，我们初步决定用hudson来作为验证。

持续集成平台无非是实现如下几个方面功能：

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 的执行单元执行结果不易做统计分析

8、hudson 的流程配置分布在不同主机，不用统一管理

如果，你们的版本足够的少，业务复杂度足够的低，不需要与什么公司内部的第三方系统做集成，我任务你需要类似于hudson这样的开源平台已经足够了。

而，如果像我们：

1、需要与公司的内部其他平台做深度的集成

2、一个持续集成流程需要分布在不同的机器，同时需要集成管理所有的流程

3、每一个大的公司都需要对结果和过程数据做统计和分析，进而实现对流程的优化

4、为了快速的推广持续集成的理念，我们需要持续集成的配置和应用足够的简单

我们选择自研持续集成平台