CI的一些背景

一直在考虑3级CI的用处，其实多级CI的关键点就是区分侧重点，就像测试金字塔一样，业内也比较认同这种多级模式，尤其在传统的硬软结合IT公司，互联网公司，大都采用这种。

目前我们公司主要是两层，主要为开发侧的master分支CI,多产品的集成CI流程，基于master+master+可能存在的中间过程库。

这边解释一下中间过程库的概念：在开发master和受控库之间，临时拉出来一个库，用来存放正在测试中的代码，验证通过后合入受控库并销毁，主要是和同类基于SVN的模式

优点：过程库存放的代码是根据需求单关联，并且同时只能修改一个功能点，最后经过串行测试通过后才能合入受控库销毁，这种情况能够尽可能的保证受控库的代码是随时可用的，极大的保证了版本质量

缺点：从上述中能看出关键词【串行】，这样会影响开发任务的并发性。同时增加了2次meger的工作量

从目前实行情况看，增加了过程库，代码泄漏率确实降低了。

但从研发角度来看，我们的CI现在还没完成【管道】级的功能，也无法做到提交即触发，其本质还是由于代码管控工具(SVN/GIT)的本身特性限制的。

我们在想，是否有个更好的方案，既能够保留上述的优点，同时弱化缺点，是否基于git也能够完成这种模式？

这幅图能够简明的描述git分支特性

我们公司目前使用的是gitlab，gitlab的特性能够支持1，2，4及后续操作(暂不考虑自动化工具的支持，仅仅从特性是否支持来描述)

业内有另外一个工具gerrit，能够满足上述的步骤，包括3步骤。

两者区别：

gitlab的页面易用性更好，功能比较强大，支持各类接口和hock，但不支持自动local分支的代码走查

gerrit的页面易用性相对弱，但能够支持local分支的代码走查。最新版本的易用性有了明显的提升

针对上述区别，加上我们公司目前已经大规模使用gitlab，有了较大的基础。准备验证在gitlab上做尝试第一级CI,目标是独立管道，自动按照分支运行，方案后续完善。