Day30-2 - GitLab CI 还可以怎麽重构及整理 .gitlab-ci.yml ？

上一篇举了一个小例子来说明，一般遇到比较冗长的 .gitlab-ci.yml 大致上可以怎麽思考整理及重构，那麽平常在规划及设计流水线的时候该怎麽注意呢？

一、GitLab 怎麽谈如何让 YAML 变得更好？

在 GitLab 的部落格中，有一篇谈论着怎麽让 YAML 设定控制着的流水线(Pipelines)越来越好的文章，内容不难，提到了三个很实用的小技巧，首先是：

1. 让工具帮忙格式化

YAML tip #1: Let other tools do the formatting for you

许多的文字编辑器或 IDE 像是 Atom、Sublime、VS Code等等，都有提供很不错的 YAML 格式化工具，让这些工具初步的排除格式上的问题，会帮忙省去很多对於 YAML 上除错的时间，在正式上到 GitLab 进行测试前，也在透过 GitLab 的 CI lint 工具再次检测，又会再省一些时间。

2. 让它保持简单

YAML tip #2: Keep it simple

让工作流程的内容尽可能地保持简单，在 GitLab CI 的设计中，参数几乎都已经有预设值了，且这些预设值都是基於大部分的情境设定；因此，在编辑设计 .gitlab-ci.yml 的时候，如果确定预设值是可用的，就不要再设定一次，只让工作的流程保留必要的设置，如此可以让工作的内容更易於了解。

3. 如果可以，重复的使用这些设定档

YAML tip #3: Reuse config when possible

让工作流程的内容可以尽可能地重复使用，在 GitLab CI 的设计中，提供了几个方便重复使用的参数及语法，像是 Day 14 谈的 anchor、Day 15 的 extends、Day 16 的 include 等，都是很适合用来重复使用时可以使用的语法。

另外，如果团队里，许多专案都可以套用相同的工作流程，也可以思考，直接将完整的 .gitlab-ci.yml 变成多专案可以共用的流程专案，其他专案透过参数的传递等技巧，并透过 Day 26 谈及的 trigger 来做触发启动流水线。

二、多参考公开专案

重构 .gitlab-ci.yml 的内容，还有蛮多可以参考的方法，像 GitLab 官方 OpenSource 的专案中，就有许多很值得学习，在这边推荐两个，如：

• GitLab.org / gitlab-runner
  这是 GitLab Runner 的专案，他的 .gitlab-ci.yml 主档里头，大量的使用了 include 的技巧，并透过载入的档案的命名，可以充分的了解载入这个档案的目的是什麽，对於初期接触该专案的人，也可以透过这些命名，快速的找到自己该看的流水线工作内容。

• GitLab.org / Auto Devops v12.10
  GitLab 的 Auto Devops 是很好用的，他的 YAML 内容也是相当经典值得学习的好范例，其进入点有两个，一个为：Auto-DevOps.gitlab-ci.yml，另一个是：Auto-DevOps-remote.gitlab-ci.yml 这两份有一个共同的特色，它把 GitLab CI 的 workflow rules 利用到非常的极致。透过 workflow:rules 判断存在什麽档案，而後进行对应的工作流程。

  其他关於 rules 在 Day 10 的内容中有谈论到，主要可以参考官方文件的 workkflow:rules。

三、总结：

这是属於铁人赛 30 篇文章的第 30 篇，这三十天让自己重新的学了一次 GitLab CI 流程的设定，一来也是 GitLab 的更新速度很快，二来也是在写文章的当下才又发现有些细节一直没往下追究，是一个不错的学习体验。

手上其实还有一些排定，但後来暂时不写的内容，主要是有些不是太常用，或判断後觉得重要不没那麽重要，所以先留着之後再继续补齐，像是自动完成 GitLab Release 页面、让单一工作取得 code coverage、取得 submodule 内容的小技巧、 不用定义也存在的两个 stage .pre 和 .post 等等。

我是墨嗓(陈佑竹)，期待这系列的文章能够让人有些帮助。

四、参考资料：

• 3 YAML tips for better pipelines | GitLab