ZCIP编年史-技术选型

ZCIP（软创的持续集成平台），对于这个产品，我投入的精力和感情很多，前端时间我们领导写了篇关于基于自研持续集成平台完成持续集成落地推广的文章，小有感慨。我就想着我是否要去思考编写下关于ZCIP发展的编年史，来详细的聊一聊ZCIP，我们自研的持续集成平台。

第一篇，ZCIP的技术选型篇

我们要研发持续集成平台，那么首先要明确什么是持续集成，百度百科的定义：

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

从持续集成的实践描述，我们可以总结出持续集成平台为了支撑持续集成实践所需要必备的如下特性：

可视化：可视化是一切需要快速、简单、明白的传递消息的基础。开发团队进而能够直观的获取构建的各种状态。

任务流程化：持续集成的实践包括一系列的任务，而任务间有的存在上下文依赖，有的没有，和流程引擎高度吻合。

消息提醒：除了可视化，消息提醒也是快速反馈必不可少的

数据累积和分析能力：为了更好的支撑持续集成实践活动，那么必然要对实践环节的各数据进行积累、分析和总结，以达到持续改进的数字化支撑的目的。

快速接入：持续集成的实践是为了更好的是研发流程顺畅，那么持续集成平台一定需要更加简单易用，满足绝大多数用户的需要。

针对持续集成平台的这些特性，我们当时针对开源产品做了简单的分析和总结，最终两个作为备选方案，Jenkins，GoCD（不太清楚那个时候他们是不是叫这个，当时go应该是根据agent的数量进行收费的）

GoCD的架构是server-agent的模式

Jenkins的架构Master/Slave的模式

分析这个前我们先聊聊开源选项的一些基本共识：

1、发展趋势

2、社区活跃度

3、产品当前所处的阶段

对比这些方面Jenkins都是更好的选择，那个时候的jenkins还不具备Pipeline的能力

接下来我们来具体分析我们自己的需求和我们的能力储备：

需求：

除去持续集成平台的共性我们还需要什么：

1、前期落地各种规则的统一管理和实施控制

2、内部系统的集成

3、持续改进的数据搜集

4、个性化规则定制

5、用户的特点（我们当时面对的绝大部分用户，自定义的脚本编写能力都比较弱，他们更加愿意可视化的交互操作，点点点）

团队成员的能力模型，这是在考虑引入某种技术和产品时非常重要的关注点

团队成员当时的能力模型，我们团队当时的实际情况如果去对jenkins做大氛围的定制化改造和接入，可能团队成员有绝大部分都需要一定的时间。对于快速的要落地持续集成有一定的难度。

再分析持续集成平台到底有什么，说简单点，就是一个server-agent的架构下的，调度引擎+节点任务执行器。jenkins的当时能够带给我们的是一个调度引擎（当然它还具备很多功能，不过我们至今很多功能可能都用不到），然后就是一些新的任务节点的插件接入。对于一个持续集成平台可能后者，新的节点插件是后续会持续增加的任务，我们分析了下，新的插件其实都是一种CLI的开源工具，对于我们接入来说包装起来也非常的方便。

但考虑我们自己的一些特性，我们最终选择自己来研发一套持续构建平台内部名称ZCIP。

对于第一代的持续集成平台，我们的主要精力放在了，怎么是闲置和以后资源的快速接入、数据如何快速搜集、如何简化配置、如何友好的呈现构建流程、如何个性化的消息提醒。

截几张图：

主页：

任务流程：

消息邮件一部分：

下一篇来聊聊我们持续集成平台的演进，dailybuild每日编译--CI持续集成平台--容器化的持续交付全流程