UCloud内部长期使用Gitlab来管理代码。虽然Gitlab作为一套开源平台已很优秀,但我们对于其能为CI/CD提供的敏捷性并不十分满意,内部实践中的代码发布周期仍需按天计算。为此,我们打造了一个基于Kubernetes的内部容器服务平台(名为库恩),用于托管内部服务,并将Gitlab对接到库恩平台,从而借助Kubernetes的云原生优势,获得更好的CI/CD效果。这套系统运行一年内,Gitlab的管道一共触发了994次,执行了约20000 +次工作,在测试环境和正式环境一共进行了7000 +次部署,即每天部署约20次。以下是该项目的一些实践经验。
<强>我们对CI/CD的目标
CI即持续集成(持续集成),指代码集成到主干之前必须通过自动化测试,只要有一个测试用例失败,就不能集成。目的是让产品快速迭代的同时还能保持高质量。
CD有两种意思:
持续交付,持续交付,指的是任何的修改都经过验证,可以随时实施部署到生产环境。
持续部署,持续部署,是持续交付的更高阶段,指的是任何修改后的内容都经过验证,自动化的部署到生产环境。
两者的区别,在于是否自动部署到生产环境。对UCloud而言,肯定要以后者,也就是持续部署为目标。
<强> Gitlab分支管理
我们采用的Gitlab分支管理模型在接入库恩平台前后并未发生变化,故简述如下:
主:主分支,代码经过验证。从主创建标记进行版本。
dev:研发主分支,用于合入特性分支和补丁分支,在此分支。
临时分支:
特性分支:用于开发某个特性;
补丁分支:用于修复线上错误。
下面以一个实例来介绍CI/CD开发流程.StepFlow是UCloud新近推出的一款可视化工作流产品,通过StepFlow用户可以灵活便捷地定义自己的工作流,快速实现业务功能。整套StepFlow系统由多个模块组成,并全部部署在Kubernetes集群上。
在实例中,我们需要开发其中名为optimize-allocate的一个特点:
则开发流程为:
-
<李>
首先,在Gitlab上创建了编号为80的问题,跟进这个optimize-allocate的特性;
李 <李>从dev分支创建一个新分支,名/80 -优化分配为特征,在该分支上进行开发;
李 <李>在功能/80 -优化分配上开发完成,进行提交此时会触发静态测试,单元测试,审查等管道工作;
李 <李>测试通过后,创建一个从特性/80 -优化分配到开发的请求合并,由负责人进行审核。审核通过并且合并成功后,触发静态测试,单元测试,镜像构建,镜像部署,集成测试等管道工作;
李 <李>测试通过后,创建一个从开发到主人的mergerequest,由负责人进行审核。审核通过并且合并成功后,负责人创建标签v1.1.1,然后触发静态测试,单元测试,镜像构建,镜像部署,集成测试等管道工作,李注:版本号标签是有命令规范的,v {x}, {y}。{z}代表着v{主版本},{次版本},{小修订版本}
<强> Gitlab CI/CD管道
8.0版Gitlab本以后,默认集成并开启了Gitlab-CI,是可以提供一定CI能力的,我们以此搭建持续集成的流水线,其中有管道,阶段和工作三个层级需要设计。
<强>管道
Gitlab会检测一个项目的根目录下的.Gitlab-CI。yml文件,用户可在该文件中定义CI/CD管道,一个管道代表了CI/CD的整个过程。代码发生变化时(比如,标签,合并等),将触发一个管道的运行。
<强>阶段
一个管道包含多个阶段,比如“静态检查”、“单元测试”、“构建镜像”等等,这些阶段一个接一个顺序执行。
<强>工作
每一个阶段可以包含多个工作,同一个阶段的所有工作同时执行。每个工作需指定若干个重要属性如形象,舞台,标签、服务等。
在StepFlow例子中,针对要开发的特性,其管道设计如下,包括静态检查,单元测试和最后的两个手动代码复查:
