持续集成--Gitlab-CI

玺同学
867 阅读5分钟

前言

GitLab-CI就是一套配合GitLab使用的持续集成系统，在GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

基本的CI工作流程

当我们push代码到远程分支时，会触发GitLab-CI：

  1. 执行自动化脚本，构建并检测项目
  2. 若检测通过，则可以进行review；若未通过，则修改后重新push，再次执行第一步
  3. 若review通过后，则merge代码，会再次执行自动化脚本，检测项目并进行交付

image

.gitlab-ci.yml

要使用GitLab-CI，首先需要在根目录下添加.gitlab-ci.yml，用来记录CI需要执行的操作。当触发CI操作时，GitLab-CI会读取.gitlab-ci.yml中的信息。

这是一个YAML文件，因此您必须格外注意缩进。始终使用空格，不要使用制表符。

下面介绍一下.gitlab-ci.yml的主要元素。

Job

Job是.gitlab-ci.yml文件的最基本元素。

  • Job定义了约束，即什么条件下执行
  • Job为具有任意名称的顶级元素(需要避开保留字)，并且至少有一个script子语句
  • 不限制Job的数量
job1:
  script: "execute-script-for-job1" // 单个子语句

job2:
  script: // 多个子语句
    - bundle exec rspeca
    - bundle exec rspecb

每个Job在Runner(即GitLab-Runner，下文有介绍)中彼此独立运行，多个Job形成了CI的Pipeline配置步骤。

关键字

除了script是Job的唯一必需关键字外，Job还有其他关键字：

  • environment 用于定义Job部署到指定环境
  • image 用于指定用于Job的Docker映像
  • stage 用于定义Job的阶段，和全局关键字stages配合使用，可以在特定环境下并行执行相同stage的Job
  • timeout 用于设置Job的超时时长
  • rules 用于Job进行判断。其中的if属性可以根据变量$CI_PIPELINE_SOURCE的值来进行判断
  • 。。。

更多的关键字可以查询这里。

全局关键字

除了在每个Job中定义关键字，也可以定义全局关键字。

  • stages 用于定义包含Job的所有阶段，其中元素的顺序决定了对应Job的执行顺序
stages:
  - build
  - test

ob 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test
  • 也可以使用default来定义一些默认值，针对所有Job生效。
default:
  image: ruby:2.5

rspec:
  script: bundle exec rspec

rspec 2.6:
  image: ruby:2.6 // 覆盖了默认值ruby:2.5
  script: bundle exec rspec
  • 还有其他的全局关键字可以查看这里

GitLab-Runner

GitLab-Runner是配合Gitlab-CI使用的，是一个用来执行软件集成脚本的东西，可以是虚拟机，VPS，裸机，Docker容器，甚至是一组容器。

当GitLab中有代码修改时(比如push代码)，GitLab会通知GitLab-CI。这时GitLab-CI会找到并通知关联的GitLab-Runner，GitLab-Runner则会把项目代码下载到本地并执行预先设计好的脚本。

GitLab-Runner有两种类型：共享型(Shared Runner)和私有型(Specific Runner)。

  • Shared Runner 需要管理员安装配置，所有项目共用，但是最好在yml文件中设置不同docker 镜像(image)用以区分
  • Specific Runner 可以有项目权限的人员安装配置，每个项目私有

安装GitLab-Runner

在使用GitLab-Runner前，我们需要先进行安装。GitLab-Runner有三种安装方法：使用Docker，手动下载二进制文件或使用rpm/deb软件包的存储库。

这里我们简单描述下私有型GitLab-Runner安装：

注：由于项目中使用的是Window10-64位作为测试服务器，所以这里的私有型GitLab-Runner安装，及下面的注册等内容都是基于该服务器，若使用其他环境请参考官网。

  1. 在系统中的某个位置创建一个文件夹，例如：D:\GitLab-Runner。
  2. 下载exe文件(x86可下载这个)
  3. 将下载的gitlab-runner-windows-amd64.exe文件重命名为gitlab-runner.exe，并移动到D:\GitLab-Runner中

注册GitLab-Runner

这时准备工作就已经完成了，需要开始GitLab-Runner的注册。而GitLab-Runner的注册需要先在GitLab项目-设置-CI/CD-Runner中获取gitlab-ci coordinator URL和token：

获取相关信息后，就可以在cmd中进行注册执行了：

  1. 打开D:\GitLab-Runner，然后输入gitlab-runner.exe register，并回车
  2. 输入gitlab-ci coordinator URL，用以找到对应的Gitlab
  3. 输入token，用以注册Runner
  4. 输入Runner的描述信息
  5. 输入Runner的tag，以逗号分隔
  6. 输入Runner的执行场景，这里我选的是sell

当然，具体配置什么按照各自的项目来确定，可以参考官网。

当注册完毕后，你可以在D:\GitLab-Runner里发现config.toml文件，该文件是Runner的配置文件。

启动服务

你可以直接启动Runner服务：

./gitlab-runner.exe run

你也可以将Runner设置为系统服务：

// 使用当前用户帐户的有效密码
./gitlab-runner.exe install --user ".\ENTER-YOUR-USERNAME" --password "ENTER-YOUR-PASSWORD"

// 启动服务
./gitlab-runner.exe start

// 暂停服务
./gitlab-runner.exe stop

服务启动后，可以在GitLab项目-设置-CI/CD-Runner中查看到当前Runner的状态：

pipelines

当我们配置好Runner后，就可以在分支中添加.gitlab-ci.yml进行简单测试：

// .gitlab-ci.yml
build:
  tags:
    - test-master
  script:
    - npm install
    - npm run build

我们将修改后的代码推送到远程gitlab，就可以在CI/CD-pipelines中看见当前CI的执行状态：

点击pipelines中的状态，就可以查看所有Job的执行状态：

点击Job，也可以查看Job的详细流程：

总结

使用Gitlab对代码进行版本管理时，可以使用Gitlab-CI进行持续集成。

在使用Gitlab-CI前，需要完成.gitlab-ci.yml和Gitlab-Runner的配置。在push、merge等操作时，触发持续集成，可以在pipelines中查看进行状态。

参考

avatar
文章
阅读
粉丝