CI/CD系列 | 一步上手Gitlab CI/CD

bluesGavin
6,403 阅读7分钟

本系列将会从宏观角度，讲述CI/CD相关知识。系列文章不求把每一项都讲仔细，而是让大家能对CI/CD整体流程有大致的概念。无论你是前端，后端，或是运维团队，只要是CI/CD链路上的一份子，相信这系列文章对你都会有帮助。 阅读更多专栏文章

今天我们开始讲述CI/CD工具了，本文会涉及CI/CD的全环节

为什么选择Gitlab CI/CD？

如今市面上的 CI/CD 工具有很多，如 Jenkins，CircleCI，Bamboo 等，而本文将讲选取 Gitlab CI/CD 进行讲述。

其中原因有下：

  • 大部分开发团队都会选择内部搭建 Gitalb 作为代码仓库，而 Gitlab CI/CD 内置在 Gitlab 中，不需要额外安装。
  • Gitlab CI/CD 的功能丰富，足以应对大部分devops场景。
  • 其中流水线的功能，概念简单，开发者上手门槛低。

概念

在使用 Gitlab CI/CD 之前，我们需要先了解一些概念，这可以帮我们更容易理解整个 Gitlab CI/CD 运行流程。

流水线(Pipelines)

Gitlab 把在项目中触发的一系列 CI/CD 任务合称流水线。 通常开发者会把 CI/CD 中的任务按逻辑划分为诸如测试，构建，部署等。而这些任务会按顺序一个接着一个执行，如同工业流水线一般。

你可以在代码仓库点击左侧菜单看到当前的流水线信息

任务(Jobs)

任务是组成流水线的基本要素，是流水线中具体的某个工作。开发者可以自行描述这些任务的内容与执行方式。

你可以在代码仓库点击左侧菜单看到当前的任务信息

环境变量(Variables)

环境变量不是 CI/CD 的必要部分，但在某些场景下可以完成一些特别需求，因此这里也顺带提一下。

这里说的环境变量准确来说应该是共用变量，需要开发者在仓库配置栏中手动配置。

一旦配置之后，在流水线就可以直接使用改变量的信息。因此一般被用作需要保密信息的记录，如账号密码等。 除此之外，还可以以文件形式保存，但要注意的是当用文件作为变量时，在流水线使用时变量代表的不再是文字内容，而是文件的路径。

使用

接下来，我们可以开始使用 Gitlab CI/CD 了，但在开始之前，大家需要确认项目中有可用的 Gitlab Runner。

更多关于 Gitlab Runner 的信息，可以参考我的上一篇文章《CI/CD 系列 | 一文让你掌握 Gitlab Runner》。

创建流水线

建立CI/CD 的第一步，就是创建流水线。而在 Gitlab CI/CD 中，创建的操作非常简单，就是创建一个配置文件 .gitlab-ci.yml 。在Gitlab的代码仓库根目录下，只要有 .gitlab-ci.yml 文件，就会认为当前仓库已经激活 CI/CD 了。

创建任务

接下来，我们开始创建我们的第一个任务。先修改 .gitlab-ci.yml 文件为以下内容：

first-job:
	script: echo "第一个任务！"

然后把修改提交commit，再push到远程仓库。一旦代码push成功之后流水线就开始了。我们可以在pipeline面板看到。

点击对于的job(这里job的名称是first-job)，可以看到具体的执行输出内容。

可以看到我们的第一个任务已经成功跑起来了。

优化配置

现在我们回过头来看看刚刚配置的 .gitlab-ci.yml 都做了些什么：

## 声明一个名字为first-job的任务
first-job:
	## 任务的执行脚本，这里是在终端打印字符"第一个任务！" 
	script: echo "第一个任务！"

事实上在实际运用时，我们的任务会更加的具体：

## 声明一个测试任务
test:
  ## 由于我用的是docker类型的runner executor，因此需要指定对应的image。如果不指定，会使用默认镜像
   image: node:16.14.2-slim
   script: 
    		## 在运行测试之前需要安装依赖
      - npm install --registry=https://registry.npmmirror.com
      - npm run test

重新提交之后，可以看到流水线再次执行，但这次job的名字已经改成test了。

点击进入后，看到新的内容输出也改变了

完善CI/CD链路

经过上方操作之后，其实你已经掌握了 Gitlab CI/CD 的基本操作了。剩下的无非就是完善各个环节的任务，为此我们可能还需要一些配置。

阶段(Stage)

正常我们在CI/CD中会有多个任务，如测试 ，构建，部署等。但我们不能如下方配置一样，直接建立执行这些任务：

test:
	script:
  	- npm install --registry=https://registry.npmmirror.com
  	- npm run test

build:
	script:
  	- npm run build

deploy:
	script:
  	- npm deploy

上方配置是一个错误示范，我们这里定义的3个任务(test,build,deploy)是并行进行的。流水线触发时，它们在各自执行，互不相关。但实际上，我们是希望它们按顺序逐个进行，如果前一个执行出错后，后面的任务应该不会执行。

此时，我们需要用stage来描述流水线的各个阶段：

# 定义三个stage
stages:
  - test
  - build
  - deploy

test-job:
	# 注明该任务在test阶段执行
	stage: test
	script:
  	- npm install --registry=https://registry.npmmirror.com
  	- npm run test

build-job:
	# 注明该任务在build阶段执行
	stage: build
	script:
  	- npm run build

deploy-job:
	# 注明该任务在deploy阶段执行
	stage: deploy
	script:
  	- npm deploy

修改完之后，再次触发流水线。可以看到现在的流水线会按阶段区分各个任务，并按顺序执行。

指定执行Runner

有时候我们希望不同的项目，由不同的runner执行。这可以通过配置tag来关联执行的runner。

如下图，现在我的项目有2个可用runner，其中一个没有tag，一个有名为local的tag。

我希望test阶段的任务在我的local runner中进行，其他任务在test2 runner中进行。只要如下修改配置即可：

stages:
  - test
  - build
  - deploy

test-job:
	stage: test
	script:
  	- npm install --registry=https://registry.npmmirror.com
  	- npm run test
  	## 用local runner执行
	tags:
  	- local

build-job:
	stage: build
	script:
  	- npm run build

deploy-job:
	stage: deploy
	script:
  	- npm deploy

限制任务执行条件

现在还有一个问题，某些任务我希望是在代码merge或者仓库打tag之后才执行，而不是每次提交代码都要执行。也就是说我们需要限制任务的执行条件。

实现这一步，我们需要用到配置项 rules。直接上例子：

job1:
  script: "echo Hello, Rules 1!"
  rules:
  	## 只有在代码 merge 到 master 分支时才会执行。
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
      when: always

job2:
  script: "echo Hello, Rules 2!"
  rules:
  	## 只有在代码 commit 到 dev 分支时才会执行。
    - if: '$CI_COMMIT_BRANCH == "dev"'
      when: always

job3:
  script: "echo Hello, Rules 3!"
  rules:
  	## 只有在代码 commit tag 时才会执行。
		- if: '$CI_COMMIT_TAG != null'
      when: always

job4:
  script: "echo Hello, Rules 4!"
  rules:
		## 只有在仓库目录下存在 package.json 文件时才会执行。
    - exists:
      - package.json

上方我选取了四个很常用的例子，相信大家可以看出rules的用法，是由”规则+执行方式“ 的形式构成的。其中可用规则有：

  • if ：一般用变量加正则的方式配合使用。
  • exists：根据某个文件是否存在进行判断
  • changes： 根据某个文件是否被修改进行判断

而执行方式 (when) 有：

  • on_success (默认项): 前面的所以阶段任务都成功或者设置了 allow_failure: true 才会执行。
  • manual: 需要手动触发
  • always: 总是会执行
  • on_failure: 只有上一个任务失败才会执行。
  • delayed: 延迟执行
  • never: 不执行

总结

今天我们正式学习了 Gitlab CI/CD 的使用，掌握了其中的各个概念。要基本使用 Gitlab CI/CD 并不困难，开发者要做的，是细心思考项目 CI/CD 流水线的设计，从而实现真正的自动化DevOps，解放团队成本。当然，Gitlab 官方提供的可定制化操作远不止如此，有兴趣的朋友可以自行进一步了解。

进一步阅读

Gitlab CI/CD 官方文档：docs.gitlab.com/ee/ci/

.gitlab-ci.yml 配置详细说明： docs.gitlab.com/ee/ci/yaml/

如果你觉得本文对你有一点帮助，麻烦给我点个赞吧~~ 谢谢

avatar
文章
阅读
粉丝