部门持续集成的后续思路

今天我要先讨论一下,我们部门里边后续做这个持续集成的建设思路。

首先,说一下我对这个建设思路的总体的一些想法。我们主要是想建设一个标准化,集中化,自动化的持续集成解决方案。

什么是标准化?我认为就是学习成本比较低,有一些套路,新人来了之后可以很快的上手。这个集中化呢,我觉得就是配置脚本都是要集中化的,集中在一个地方去管理,而不是分散在各个角落,它或许是存在于这个代码仓库里边,另外集成环境的机器也是对等的,环境没有差异。最后一个自动化,应该是比较好理解的,就是减少人工的干预,过程可以预测。

简单来说,一个任务,做法要标准化,多个任务,是集中管理的,所有任务,都是自动管理的。

我现在来总结一下,当前我们的一些进展,去年的时候我们都已经是使用这个Jenkins了,然后又引入了这个K8S来管理这个Jenkins的所有执行节点,已经在很大程度上解决了集中化部署的一些问题。当前已经托管了上百个代码工程,一个月数万次构建任务,还算稳定。

另外我们构建了一个叫pipeline的Jenkinsfile文件集中管理的工程,实现了gitlab和Jenkins的配置的统一管理,对于常见的代码工程,我们可以很方便的管理它的持续集成脚本,也不需要关心Jenkins的配置和gitlab的配置究竟是怎样的,这些都可以做到自动管理的。

后面我们对于原来在svn上的一些工程,肯定将逐步迁移到这个工程上,这个问题不大。在这个基础上后续要开展第三方依赖管理的管控工作也比较方便。

但是我们还有不少是CMO(配置管理员)他们才需要的脚本,例如部署到各个环境的脚本,例如做一些清理,扫描工作的东西,这些脚本呢,目前来说啊,我觉得是没有一个统一的标准管理,散落在各个服务器,或者是组织形式也不完全相同,实现思路也千差万别。

我有个想法,就是把这些脚本的集中化的管理,然后呢,按配置即代码的思路,通过一套DSL(job dsl plugin)把他们生成对应的Jenkins任务,这样我们只要在一个地方(某个代码仓库)维护,很容易做一些标准化的脚本或操作。

当然,这里还有其他一些实现思路,例如打造一个发布管理用的工具,但是呢,这个就看CMO他对这个东西的接受程度,或者是迫切程度,或者是他们更期望使用jenkins这种比较熟悉的方式来管理他们的脚本。

我觉得这两种方式都没有什么问题,但是最主要是先要对齐我们这个集中化的思路,用标准化的方式去做这个事情,并且尽快的开展起来。