实践中我们将展示我们的三种代码分支策略

DevOps微课系列旨在帮助用户学习DevOps实践。

业务背景

问题一：

现有CI上的构建项目无法完成UT/FT/ST等测试及SM复杂度或Lizard圈复杂度检查。

现有CI上的构建项目只能对版本控制源代码，而测试代码、数据库脚本、构建和部署脚本、依赖的库文件等，并且对构建产物的版本控制也同样重要，只有这些内容都纳入版本控制了，才能够确保所有的开发、测试、运维活动能够正常开展，系统能够被完整的搭建。

普通pipeline无法对多个branch进行支持，无法对Gerrit trigger触发的DailyCI、VerifyCI、MergeCI合并在同一个构建项目中，导致pipeline流水线很多，管理复杂。

问题二：

现有的版本发布是将版本编译目标文件打包上传制品库，在环境部署过程中需要提前配置主机环境，如果环境较为复杂和繁琐，给环境配置带来不小的困难。采用docker方式打包环境和版本利于测试部署和现网部署。

解决思路

1.通过multibranch类型的pipeline job使得对于多个branch的支持更加简单。

只需要创建一个multibranch job，jenkins将自动地为所有的branch创建job。

2.构建docker环境并打包编译版本到镜像中，将镜像pull到制品库。

实践情况

解决方案中我们明确了gerrit上代码分支管理策略，对不同的分支版本采用不同的分支策略，在实践中我们将展示我们的三种代码分支策略。

1.代码分支策略1——开发分支与发布分支

2.代码分支策略2——特性分支（临时分支）

3.代码分支策略3——修复Bug分支

解决方案

解决方案中我们还详细阐述了我们的CI创建，包括Multibranch Pipeline创建，Jenkinsfile的撰写、存放及调用，完整效果预览。

1.新建multibranch pipeline job

2. 每个分支代码的根目录下存放Jenkinsfile,撰写jekinsfile脚本

脚本分如下几个部分：

1） Jekinsfile中添加接收gerrit 触发事件的Properties

配置成功后在Branches中查看配置，会看到自动生成的配置触发页面为

2）获取verifyCI需要的gerrit上change分支

3） 脚本处理不同的gerrit上的branch分支

4） 脚本处理不同的gerrit触发事件

3.自动为每个branch生成job

在multibranch pipeline job保存后，jenkins自动地检查所有的branch，且自动地为所有的branch创建job,当然前提是存在jenkinsfile文件。例如上面的job，自动地生成了文件夹*-AI-*-RUNNTIME，且在此文件夹下自动地为trunk和branch生成了job。如果在代码库上某个branch分支被删除，multibranch pipeline也会自动检测变化并删除相应的job。

4.Scan Multibranch Pipeline Now第一次生成Multibranch Pipeline时，会自动扫描pipeline配置文件并建立相应的job,后续如果jenkinsfile文件有变更，也可以手动触发扫描，日志输出如下

5.这样建立完成一个完整的MultiBranch Pipeline

不同任务运行效果图如下所示，在同一个pipeline中可见并管理不同的gerrit触发任务，比如patchset-created、change-merged和daily_ci。

6.Gtest+lconv代码单元测试及覆盖率检查

输出gtest单元测试及lcov代码覆盖率检测结果

7.Docker镜像通过制品库发布