Gitlab CI/CD浅谈模板拆分

微信公众号：运维开发故事，作者：姜总

GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：

• Continuous Integration (CI) 持续集成

• Continuous Delivery (CD) 持续交付

• Continuous Deployment (CD) 持续部署

持续集成的工作原理：将小的代码块推送到如GitLab代码仓库中托管，并且每次推送后都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。

持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。

1、GitLab CI/CD是如何工作的？

---

使用GitLab CI/CD，前提需要有一个托管在GitLab仓库上的代码仓库，并且在该项目代码仓库的根目录下存在一个名为：.gitlab-ci.yml 的文件。该文件中指定代码扫描、构建、测试、部署等几个步骤的一系列的命令或者脚本。在该文件中，你可以定义要运行的脚本，定义包含的依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在何处部署应用程序，以及指定是否 要自动运行脚本或手动触发脚本。当项目根目录中存在已经定义好的 .gitlab-ci.yml 文件时，这时候开发人员将代码提交到代码仓库中，GitLab就会检测到并使用GitLab Runner根据 .gitlab-ci.yml 中定义的步骤来运行pipeline流水线(有可能需要符合workflow规则)。

2、创建一个 .gitlab-ci.yml 文件

---

说了这么多，这里用一个简单的例子来介绍。如下：

假设目前我们的Gitlab Runner已经注册并且可用。

假设我们在GitLab代码仓库中存在两个project项目：gitlab-ci-template 和 demo-java

gitlab-ci-template就是我们存放gitlab-ci-template.yml的模板文件，demo-java是我们开发人员的java代码仓库。

2.1、 开发人员的代码仓库下的 .gitlab-ci.yml的文件:

variables:
  DOCKER_IMAGE_NAME: $DOCKER_REGISTRY_URL/${CI_PROJECT_NAMESPACE}/$CI_PROJECT_NAME:$CI_PIPELINE_IID-$CI_COMMIT_SHORT_SHA

stages:
  - maven
  - build
  - deploy

maven:
  stage: maven
  image: www.ayunw.cn/allenjol_containes/build-maven:v1
  tags:
    - default
  script: 
    - mvn deploy -B -Dmaven.test.skip=true
  artifacts:
    name: maven_build_package
    paths:
      - target/*.jar
    expire_in: 1 week

Build-java:
  stage: build
  image: www.ayunw.cn/allenjol_containes/build-java:v1
  tags:
    - default
  script:
    - echo "java build..."

Deploy:
  stage: deploy
  image: www.ayunw.cn/allenjol_containes/deploy:v1
  tags:
    - default
  script:
    - echo "deploy..."

2.2、 推送 .gitlab-ci.yml 文件到代码根目录

---

git add .gitlab-ci.yml
git commit -m "add .gitlab-ci.yml"
git push origin master

接下来当开发提交代码以后就会触发Gitlab Runner，根据该 .gitlab-ci.yml 文件运行pipeline。

3、以上.gitlab-ci.yml 存在的问题

---

以上的步骤相对比较简单，一般也不会有什么问题。但是存在两种情况会比较麻烦。

问题一：开发人员随便乱改这个文件。

问题二：篇幅过长看着很乱。

问题三：不易于统一更新维护。

4、解决步骤三中存在的问题

---

步骤三存在的问题比较麻烦。这时候我们想到一个方法就是利用模板拆分优化.gitlab-ci.yml

这时候开发代码根目录下的 .gitlab-ci.yml文件如下：

variables:
  BUILD_TYPE: JAVA

include:
  - project: 'Group1/gitlab-ci-template'
    ref: 'master'
    file: 'src/.gitlab-ci-template.yml'

我们模板仓库在：Group1这个组下的gitlab-ci-template目录，其中包含一个src目录，src目录下包含一个 .gitlab-ci-template.yml文件，内容如下：

variables:
  DOCKER_IMAGE_NAME: $DOCKER_REGISTRY_URL/${CI_PROJECT_NAMESPACE}/$CI_PROJECT_NAME:$CI_PIPELINE_IID-$CI_COMMIT_SHORT_SHA

stages:
  - maven
  - build
  - deploy

maven:
  stage: maven
  image: www.ayunw.cn/allenjol_containes/build-maven:v1
  tags:
    - default
  script: 
    - mvn deploy -B -Dmaven.test.skip=true
  artifacts:
    name: maven_build_package
    paths:
      - target/*.jar
    expire_in: 1 week

Build-java:
  stage: build
  image: www.ayunw.cn/allenjol_containes/build-java:v1
  tags:
    - default
  script:
    - echo "java build..."

Deploy:
  stage: deploy
  image: www.ayunw.cn/allenjol_containes/deploy:v1
  tags:
    - default
  script:
    - echo "deploy..."

上面的方法简化了开发人员代码仓库下的 .gitlab-ci.yml 文件篇幅过长的问题。并且还很有效的控制了开发人员会随便更改该文件。并且也利于运维人员统一更新。节约时间方便管理维护。

公众号：运维开发故事

github：https://github.com/orgs/sunsharing-note/dashboard

爱生活，爱运维

如果你觉得文章还不错，就请点击右上角选择发送给朋友或者转发到朋友圈。您的支持和鼓励是我最大的动力。喜欢就请关注我吧~

扫码二维码

关注我，不定期维护优质内容

温馨提示

如果你喜欢本文，请分享到朋友圈，想要获得更多信息，请关注我。

                                          ........................