GitLab CI 持续集成

简介

从GitLab 8.0开始就把GitLab-Ci集成在GitLab中了，我们只要在项目中添加一个.gitlab-ci.yml文件，然后添加一个Runner就可以进行持续集成了，GitLab-Ci实现自动化部署流程：用户提交代码->检查是否有.gitlab-ci.yml文件->如果无，则结束；如果有，则调用runner执行脚本->获取返回的结果。

概念

• pipline

一次piplien相当于一次构建任务，里面可以包含多个流程，如编译、测试、部署等。任何提交或者MergeRequest的合并都可以触发Pipline,如图：

• Stages

Stages表示构建阶段，我们可以在一个Piplien中定义多个Stages,这些Stages会有以下特点：

1. 所有的Stages会按照顺序运行，即当一个Stages完成后，下一个Stage才开始
2. 只有当所有Stages完成后，该构建任务（Pipline）才会成功
3. 如果任何一个Stage失效，那么后面Stages不会执行，该构建任务（Pipline）失效

因此，Stages和Pipline的关系是：

• Jobs

Jobs表示构建工作，表示某个Stage里面执行工作，我们可以在Stage里面定义多个Jobs,这些Jobs会有以下特点：

1. 相同Stage中的Jobs会并行执行。
2. 相同Stage中的Jobs都执行成功时，该Stage才会成功。
3. 如果任何一个Job失败，即该构建任务（Pipline）失败。

Jobs和Stage的关系图：

• gitlab runner

执行构建任务的一个服务，把构建任务放到runner里面而不是在CI里面做是不想把”构建”这个重任(通常较大的工程构建都比较小耗资源) 放到gitlab上而影响gitlab性能。通过把gitlab runner安装到不同机器上，让这台单独的机器来执行构建任务，GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）：

1. Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
2. Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

向GitLab-CI注册一个Runner需要两样东西：GitLab-CI的url和注册token。如果要注册Shared Runner，你需要到管理界面的Runners页面里面去找注册token。如下图所示：

如果要注册Specific Runner，需要到指定的项目中去找对应的token，如图：

实践

• GitLab-Runner的安装与注册

以centos 7为例, 使用了清华大学的镜像，新建 gitlab-ci-multi-runner.repo

[root@i-vvwtw5ne ~]# touch /etc/yum.repos.d/gitlab-ci-multi-runner.repo

将以下内容写入文件

[gitlab-ci-multi-runner]
name=gitlab-ci-multi-runner
baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packages.gitlab.com/gpg.key

执行

[root@i-vvwtw5ne ~]# yum makecache
[root@i-vvwtw5ne ~]# yum install gitlab-ci-multi-runner

注册一个Rnner

让Runner启动起来

[root@i-vvwtw5ne ~]# gitlab-runner start

登陆到gitlab就可以看到新注册的Runner了，如图：

配置.gitlab-ci.yml文件

在工程目录下增加一个.gitlab-ci.yml文件，内容如下：

# 缓存服务, 如果有文件需要多个stages共用，例如jar/war包
cache:
paths:
- target/

# 本次构建的阶段：build package
stages:
- build
- deploy
# 构建 Job
build:
stage: build
tags:
- dev
only:
- dev
script:
- echo "=============== 开始编译构建和打包任务  ==============="
- pwd
- gradle clean build -x test
# 部署
deploy:
stage: deploy
tags:
- dev
only:
- dev
script:
- echo "=============== 开始部署任务  ==============="
# 测试，是否能够通过 ssh 连通远程服务器
- sshpass -p Falsesoul**** ssh -o StrictHostKeychecking=no root@192.192.18.73
- echo "=============== 将 jar 包部署到远程服务器上  ==============="
- sshpass -p Falsesoul**** scp -o StrictHostKeychecking=no /home/gitlab-runner/builds/66b08c53/0/cos/yh-cos/yh-cos-web/build/libs/yh-cos-web-0.0.1.jar  root@192.192.18.73:/opt/war/
- echo "=============== 开始执行  ==============="
- sshpass -p Falsesoul**** ssh -o StrictHostKeychecking=no root@192.192.18.73 "sh deploy.sh"

当有提交或Meger request到dev分支的时候，就会自动触发pipline,如图：