GitLab 不单单只是作为一个代码版本控制的仓库，很多场景下使用 GitLab 作为整合 CI 持续集成就 CD 持续发布的工作平台，那么就是 GitLab 的 CI Pipeline 功能了。

CI Pipeline

试想一下，如果开发人员只需要编写代码，而编译、打包、测试等等集成的事情以及将打包后的线上全部交付给机器自动化去完成，那对效率是不是有极大的提高呢。

什么是 CI (Continuous Integration)

持续集成是指开发人员会持续的将代码更改提交到代码仓库中，更改会触发编译、测试等作业证明此次提交的代码是否满足预期要求，已确保新提交代码可以对原有代码进行集成，已防止新提交的代码造成部署后应用出现问题。

什么是 CD (Continuous Delivery)

持续交付是指持续集成的进一步扩展，已经正常通过测试及验证代码的稳定性，下一步就是将代码部署在预发环境中，可以使用自动化的方式重复的进行频繁的交付，这可以避免因为人工配置错误等原因造成问题。

从一个流水线说起

GitLab 中通过 .gitlab-ci.yml 来定义Pipeline、Stage、Job，该文件存在与项目的根目录下，当有代码提交时，将自动化触发到该流水线的作业。

stages 代表阶段，例如流水线会包括编译、部署、测试等步骤。
Job 代表作业，例如在编译阶段的作业是处理依赖等。

该示例定义了 master 分支下提交代码时会触发到流水线的作业，分别会助兴 build、deploy 和 test，简单的通过输出回显代表所执行的作业。

stages:
  - build
  - deploy
  - test


default:
  before_script: - echo 'run some command before'
  after_script: - echo 'run some command '


prod-build:
  stage: build
  only: - master
  script: - echo "run some dev build code"

prod-deploy:
  stage: deploy
  only: - master
  script: - echo "run some prd deploy code"

prod-test:
  stage: test
  only: - master
  script: - echo "run some prd test code"

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
 

验证 .gitlab-ci.yml 语法是否正确

得到输出验证结果

GitLab Runner

由于当前 GitLab 服务中没有部署任何的 GitLab Runner，所以会见到该流水线作业是在 Pending 状态的。

GitLab Runner 部署

在这里也是通过 Docker 容器的形式去运行 GitLab Runner，并连接到 GitLab Server 中来。

创建 GitLab Runner

docker run -d --name gitlab-runner gitlab/gitlab-runner:v13.5.0

注册到 GitLab Server

docker exec -it gitlab-runner gitlab-ci-multi-runner register

注册时需要用到的 URL 及 Token 通过访问 Admin Area 下的 Runners 功能获取。

相关定义的流水线已经被 GitLab Runner 运行，并且每一个 Stage 都是成功的

Pipeline Schedule

可以通过计划该功能设置根据需要自动进行触发流水线作业，例如在有些场景下，团队的产品最少每天要进行一次持续集成，而这个作业由系统自动化触发。

可以按照 crontab 的形式进行定义作业的频率，并且指定所对应的分支。

文章来源: blog.csdn.net，作者：叶康铭，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/m0_38030719/article/details/109241890