Anonym0x1GitLab-CI/CD流程
GitLab提供持续集成服务。如果将.gitlab-ci.yml文件添加到存储库的根目录，并将GitLab项目配置为使用Runner，则每次提交或推送都会触发CI 管道。该.gitlab-ci.yml文件告诉GitLab跑步者该做什么。默认情况下，它运行有三个流水线阶段：build，test，和deploy。你不需要使用所有三个阶段; 没有工作的阶段被忽略了。如果一切运行正常（没有非零返回值），您将获得与提交相关联的漂亮绿色复选标记。这样可以在查看代码之前轻松查看提交是否导致任何测试失败。
大多数项目使用GitLab的CI服务来运行测试套件，以便开发人员发现问题立即获得反馈。
使用持续交付和持续部署将测试代码自动部署到模拟环境和生产环境的趋势越来越明显。
简而言之，CI所需的步骤可归纳为：
1、添加.gitlab-ci.yml到存储库的根目录
2、配置一个Runner
3、从那时起，在每次推送到Git存储库时，Runner将自动启动管道，管道将显示在项目的Pipelines页面下。
使用.gitlab-ci.yml
.gitlab-ci.yml是用来配置CI在我们的项目中做些什么工作。它位于项目的根目录。在任何的push操作，GitLab都会寻找.gitlab-ci.yml文件，并对此次commit开始jobs，jobs的内容来源于.gitlab-ci.yml文件。因为.gitlab-ci.yml是存在于我们的项目仓库中，并且受版本控制的，所以旧版本也可以执行成功，且使用CI可以让forks更容易，分支可也以拥有不同的pipelines和jobs，而且对于CI来说只会拥有单一的来源。
开始构建之前YAML文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含script部分：
2
3
4
5
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
上面这个例子就是一个最简单且带有两个独立任务的CI配置，每个任务分别执行不同的命令。script可以直接执行系统命令(例如：./configure;make;make install)或者是直接执行脚本(test.sh)。任务是由Runners接管并且由服务器中runner执行。更重要的是，每一个任务的执行过程都是独立运行的。
每个作业必须具有唯一的名称，但有一些保留keywords不能用作作业名称：
- image
- services
- stages
- types
- before_script
- after_script
- variables
- cache
定义作业行为的参数列表:
| Keyword | Required | Description |
| script | yes | Runner执行的命令或脚本 |
| image | no | 所使用的docker镜像，查阅使用docker镜像 |
| services | no | 所使用的docker服务，查阅使用docker镜像 |
| stage | no | 定义job stage（默认：test） |
| type | no | stage的别名（已弃用） |
| variables | no | 定义job级别的变量 |
| only | no | 定义一列git分支，并为其创建job |
| except | no | 定义一列git分支，不创建job |
| tags | no | 定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags） |
| allow_failure | no | 允许job失败。失败的job不影响commit状态 |
| when | no | 定义何时开始job。可以是on_success，on_failure，always或者manual |
| dependencies | no | 定义job依赖关系，这样他们就可以互相传递artifacts |
| artifacts | no | 定义 artifacts job列表 |
| cache | no | 定义应在后续运行之间缓存的文件列表 |
| before_script | no | 覆盖在作业之前执行的一组命令 |
| after_script | no | 覆盖作业后执行的一组命令 |
| environment | no | 定义此作业完成部署的环境名称 |
| coverage | no | 定义给定作业的代码覆盖率设置 |
| retry | no | 定义在发生故障时可以自动重试作业的次数 |
创建.gitlab-ci.yml作业：
我这里使用的是Bash的模板写的shell执行步骤，需要注意的是gitlab-runner执行的命令有时需要一定的权限，因为gitlab-runner安装后会自动创建一个gitlab-runner普通账户，本质上就是GitLab-runner这个用户在执行.gitlab-ci.yml中的命令。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
- echo "Before script section"
after_script:
- echo "After script section"
build1:
stage: build
script:
- echo "Do your build here"
test1:
stage: test
script:
- echo "is a test here" > /usr/share/nginx/html/index.html
deploy1:
stage: deploy
script:
- cd /usr/share/nginx/html/demo
- git pull origin master
when: manual
tags:
- Deploy
.gitlab-ci.yml文件可以在GitLab直接写，项目CI/CD中可以用CI Lint来调试验证yml的语法是否正确。或者在本地编写，然后提交到GitLab会自动触发runner执行任务。
提交.gitlab-ci.yml后，在CI/CD中Pipelines中查看流水线：
确认无误后，手动执行最后的部署阶段：
最后访问生产环境，验证是否自动部署成功。
参考资料：
