公司刚刚开始创业,因为团队人数较少,没有运维来处理 CI/CD ,之前是我在 Makefile 中定义了发布命令。最近趁闲暇之际,花了点时间来搭建了使用 Gitlab 的 Pipeline 来进行 CI/CD。
Gitlab CI/CD 的几个概念
Runner
Runner
是定义在 .gitlab-ci.yml
中的脚本的运行者。
在运行 Job 或者 Pipeline 时,Gitlab 会根据 tag
找到对应的 runner 执行相应的命令。如果找不到对应的 runner
,该 Job 就会进入阻塞状态。
Runner 需要在容器或者主机上安装 gitlab-runner
,然后根据项目或者项目组的 token
进行注册。
Stages
Stages
定义了 Gitlab 执行的阶段。执行时 Gitlab 会依次执行 stages 下的各个 stage。
Enviorments
Enviorment
可以定义不同的环境,例如 debug
, qa
, product
等,在 Operations/Environments
可以快速根据不同的环境查看 CI/CD 记录。
Tags
Tags 定义了 gitlab-runner 的 Tag。默认情况下只有 Job 定义的 Tag 与 Runner 的 Tag 相匹配,该 Runner 才会执行。也就是说 Job 执行时会找到所有匹配该 Job 下 Tags 的 Runner 并执行。
Job
Job 定义了一个任务,当发生构建时,Job 找到匹配的 Runner,并执行 Job 下定义的 script。
Pipeline
Pipeline 定义了一组 Job,通过 stages 的各个 stage 先找到对应的 Job,再通过 Job 下的 tags 找到对应的 runner,然后交由 runner 执行 Job 下的 script,这样顺序执行下去,一个流水线作业便完成了。
Gitlab CI/CD 的过程
1. 注册Runner。
首先,安装 Runner。
在 linux 下执行
1 | sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 |
来安装 gitlab-runner(其他系统参考 Install GitLab Runner)。
然后执行注册。
在 settings/ci_cd 下的 Runner 中查看相关信息。
执行 sudo gitlab-runner register
之后填写相应的信息完成注册。
注册完成后可以在该页面看到绿色的 Runner正在运行中。
2. 编辑 gitlab-ci.yml
例如我的 golang 项目 qa 环境的自动发布流程。
1 | before_script: |
3. 执行构建
将上边的文件提交到 gitlab 的 develop 分支,在默认的设置下会自动执行 format
, compile
, deploy
三个 Job。如此,一次构建便完成了。
如果需要关闭自动构建,可以把 when 下的 always 修改为 manual,这样就可以手动发布了。在 CI/CD / Pipelines 下点击 Run Pipeline
来手动执行构建。
结语
其实 Gitlab 的 CI/CD 还是比较容易理解的,我们更需要的是在使用 CI/CD 之前对 linux 比较熟稔、对自己项目的构建过程了然于心。如此,经过简单的学习便可以快速开始使用 Gitlab 的 CI/CD 进行构建,免去不规范的手动执行了。