基于GitLab实现端到端DevOps流水线实践

基于GitLab实现端到端DevOps流水线实践

基于Gitlab实现项目端到端交付实践，从需求开发开始到交付流水线实现应用发布。每个项目团队的工作流都是不一样的，本文档中的工作流是根据之前项目团队工作模式而配置的。重点参考技术的实现方式，工作流可以根据自身团队情况而定义。

1.整体规划设计

创建issue --> 创建特性分支 --> 特性分支提交流水线 --> 合并分支流水线 --> 发布分支流水线

创建issues关联特性分支 (特征以数字开头的分支为特性分支)特性分支提交代码，触发提交流水线(构建验证部署到特性环境)特性环境验证完成，合并到RELEASE分支。(触发合并流水线进行代码扫描，流水线成功才能合并)RELEASE分支手动发布 (UAT，STAG，PROD)生产发布完成后RELEASE分支合并到Master分支，并基于master分支创建Release tag。

2.需求部分准备工作

创建里程碑

创建issue，关联里程碑

根据issue名称创建对应的特性分支

3.流水线准备工作

还可以直接使用之前的java项目

准备模板库

准备可用的runner，根据之前内容安装部署runner 。

配置项目CI文件

4.提交流水线设计

开发人员在特性分支提交代码，触发提交流水线进行代码验证并发布到特性环境验证(可手动控制发布)。

阶段：编译，测试，扫描，构建镜像，上传镜像，发布特性环境

特性环境：命名规范为项目名称-ID-分支名称，每个特性分支发布到对应的特性环境。

镜像名称：

ingress域名：

Build阶段

定义build作业模板，参数化构建命令。

## build相关作业 ##  .build:   stage: build   script:      - ${BUILD_SHELL}

include:   - project: 'cidevops/cidevops-newci-service'     ref: master     file: 'jobs/build.yml'   variables:   ## 全局配置   GIT_CLONE_PATH: $CI_BUILDS_DIR/builds/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/$CI_PIPELINE_ID       GIT_CHECKOUT: "false"    ## 依赖容器镜像   BUILD_IMAGE: "maven:3.6.3-jdk-8"      ## 构建测试参数   MAVEN_OPTS: "-Dmaven.repo.local=/home/gitlab-runner/ci-build-cache/maven "   BUILD_SHELL: 'mvn clean package  -DskipTests  --settings=./settings.xml '  ##构建命令    ## 运行阶段   stages:   - build  cache:   paths:     - target/      ################# Jobs Configure ##################### ## 构建作业 build:   variables:     GIT_CHECKOUT: "true"   image: ${BUILD_IMAGE}   extends: .build

定义build作业，设置作业变量GIT_CHECKOUT: "true"表示需要下载代码，默认build是我们流水线中的第一个作业所以必须设置为下载代码，否则构建失败。作业中的变量优先级高于全局。image定义我们要使用的镜像，如果采用非容器模式运行可以删除image标签。剩下的配置全部集成模板作业.build。

Test阶段

这里定义的是在运行编译后进行的单元测试。maven项目一般是mvn test,npm项目一般是npm run test等。不同的项目运行单元测试的指令不通，其他部分都差不多。这里以maven项目为例。开始设计maven项目单元测试。

编辑jobs/test.yml文件定义test作业模板。(后续自动化测试等测试相关作业放到此文件)

#单元测试 .test:   stage: test   script:     - $TEST_SHELL   artifacts:     reports:       junit: ${JUNIT_REPORT_PATH}

编辑模板文件，添加导入test作业模板。

include:   - project: 'cidevops/cidevops-newci-service'     ref: master     file: 'jobs/build.yml'   - project: 'cidevops/cidevops-newci-service'     ref: master     file: 'jobs/test.yml'

在模板文件中添加变量定义。

variables:   TEST_SHELL : 'mvn test  --settings=./settings.xml '                        ##测试命令   JUNIT_REPORT_PATH: 'target/surefire-reports/TEST-*.xml'   ##单元测试报告       ## 测试作业 test:   image: ${BUILD_IMAGE}   extends: .test   before_script:     - ls      - ls target/

代码扫描阶段

jobs/code_analysis.yml

流水线模板

templates/pipeline.yml

构建镜像阶段

jobs/build.yml

.build-docker:   stage: buildimage   script:     - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWD  $CI_REGISTRY     - docker build -t ${IMAGE_NAME} -f ${DOCKER_FILE_PATH} .     - docker push ${IMAGE_NAME}      - docker rmi ${IMAGE_NAME}

telmplate/pipeline.yml

K8S部署阶段

jobs/deploy.yml

templates/pipeline.yml

5.流水线触发控制

使用workflow:rules 进行流水线控制，我们会用到Pipeline的变量，通过变量限制条件。

排除新建分支的流水线

运行流水线您会发现，所有新创建的分支的CI_COMMIT_BEFORE_SHA为40个0。

$ export  declare -x CI_BUILD_BEFORE_SHA="0000000000000000000000000000000000000000" declare -x CI_COMMIT_BEFORE_SHA="0000000000000000000000000000000000000000"

## 流水线控制 workflow:   rules:     - if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"       when: never     - when: always

如何匹配特性分支和版本分支呢?

#$CI_COMMIT_REF_NAME =~ /\d-*/ #$CI_COMMIT_REF_NAME =~ /^RELEASE-*/  ||

合并流水线再进行构建验证

大家可以想像一下，如果是一个刚刚开始关注代码质量的团队，避免不了出现代码质量阈失败。 改进初期出现错误很正常，如果在初期就把质量阈配置的很严格，这会导致每次提交代码都会产生错误。所以我们可以适当的放开流水线的代码扫描(也就是流水线暂时不进行质量阈检查)。

如果不扫描就无法知道代码的准确质量，所以我们准备流水线仅扫描但不检查质量阈，而合并流水线会将代码质量展示在评论区。类似于这种情况我们可以设置流水线成功后才能合并。

默认是提交触发流水线运行，而设置了"流水线成功后合并"会检查原分支的最后一次提交的状态是否为success，如果是success则运行合并。 我们配置流水线在出现合并请求的时候，进行代码验证。

## 流水线控制 workflow:   rules:     - if: $CI_MERGE_REQUEST_ID

6.部署流水线实践

我们将应用的部署文件也存储在代码库中管理，可能每个应用在各个环境中的配置文件不一致。所有分为三个配置文件 deployment-uat.yml、 deployment-stag.yml、 deployment-prod.yml

jobs/deploy.yml

templates/pipeline.yml

7.发布完成后

1.将版本分支合并到master分支

2.基于master分支创建版本标签

3.关闭issues 和里程碑