Day28 - GitLab CI 如何让工作流程流水线跑快一点？之二 逐一调整

让 GitLab CI 的工作流程的流水线加速，透过上一篇的大部分解有了思考流程上的脉络，接下来要开始从每个阶段中的工作细节去思考，应该怎麽让整个流水线再次的加速。首先来谈谈，流水线加速的一些核心思考逻辑，流水线加速的三原则：

一、流水线加速三要素

要加速流水线的进行，基本可以以三个要素去考虑，分别是：工作少做点、事情做快点、做事的多一点，从流水线工作进行的每一个阶段都可以从这三个角度思考，是不是可以针对这三个要素作点什麽？

1. 工作少做点

在流水线启动之後，流水线上有哪些关卡、哪些工作基本就已经确定了，流水线要进行多久，就取决於流水线上有几个关卡，每个关卡上有多少工作需要被完成。

因此需要进行的关卡、要被完成的工作少一点，对於流水线的进行速度，有着最直接的加速。

2. 事情作快点

流水线启动後，该做多少工作已经决定，那接下来还能影响流水线进度的就剩下工作们被执行完成的速度了，因此就可以朝怎麽让工作被更快的执行完成去思考。

3. 作事的多一点

在 GitLab CI 上，真正完成流水线上关卡的工作的是执行做的 GitLab Runner，有多少的 Runner 可以完成事情，工作伫列上的工作需要等待多久才能被取出执行，也攸关着流水线能不能更快完成。

接下来开始从每个节点思考，可以怎麽从流水线加速的三个要素来加速。

二、从 .gitlab-ci.yml 到 Job Queue 思考 怎麽加快？

.gitlab-ci.yml 是 GitLab CI 工作流程中，定义流水线上关卡及工作样貌最重要的档案，从派发角度的思考，一条流水线的启动到完成流水线工作，最重要的是什麽？

1. 什麽工作先做比较好？

流水线的启动到完成，期间，最重要不一定是把工作完成，自动化流水线的加入还必须可以及早发现问题，及早让团队针对工作内容作调整。因此早点让有决定性的工作先被执行也是流水线工作顺序安排的一个策略，如这些工作真的失败了，早点失败，流水线自然会快点执行完成。这时候可以思考，什麽工作先做比较好？

• 跑的快的工作：有些工作可以很快的执行完成，像是检测当下被修改的原始码格式、Code Style 是否符合，如不符合，後续关卡的工作根本不用作。
• 有决定性的工作：全系统的单元测试都需要执行且全数通过才能让原始码 commit 到 GIT 上，应该是很多团队都遵守的规则之一，像这种有决定性的作就也很适合放在较前面的关卡中先执行，早点确认，也早点知道後续的关卡是否可以继续。

2. 每个工作都该做吗？

一个多人同时维护的专案上，流水线需要执行的工作可能相当多元，如前後端元件在同一专案上，则专案上则可能存在着前端与後端各自的测试程序。这时候便可以思考流水线上的每一个工作，真的都需要执行吗？如，当只是前端的原始码变更，则可以考虑後端的测试是否需要执行，反之亦然。

另外每个状态下的流水线启动，就都启动所有的关卡，所有的工作吗？这部分答案应该是否定的。有些工作只需要在正式版本释出的时候需要执行，有些工作只需要在 Code Review 前提供检核者判断，有些工作也只需要在特定工作完成後，接续完成，这些，都是可以思考哪些工作该做的思考方向。

针对流水线工作设置执行条件可以参考：Day 08、Day 09、Day 10 这三篇的内容，主要都在谈关於工作执行的条件设置。

3. 有没有工作花太多时间在等待进入工作伫列？

一个关卡上可能同时存在着多个工作，但这些工作彼此之间没有关系，却因为在同一个关卡中而无法让下一个关卡中与此工作相关的工作先开始执行，造成部分工作非必要的等待。有办法让後续相关联的工作先开始执行吗？在 Day 11 的内容中谈到「DAG 有向无环图」用到 needs 这个参数，就可以做到这件事情。

如上面的案例，当使用了有向无环图的机制後，甚至会发生，其中一个工作已经完成了，还有一些工作还在很前面的关卡。

可以夸张的想像，当同一时期的一些产品已经释出在贩售了，却还有同一时期的产品还在测试验证，无法出场，如果一直都被卡着无法释出，对於产品开发也是一种损耗。

三、从 Job Queue 到 Runner Server 取得工作思考 怎麽加快？

在工作伫列等待 Runner Server 的 Runner 来取得工作去执行的这段流程中，可以思考：

1. 可以取得工作的 Runner 够吗？

可以取得工作的 Runner 够吗？有些时候团队中同类型的工作能够执行的 Runner 数量是有限的，像是某些部署流程工作，可能只被限制在特定的环境中，当有频繁的部署专案需求时，就可能发生待执行工作在等待能做事的 Runner 来完成部署工作。

这时候为了要加速流水线完成，就可以思考，是否增加这类型的 Runner 数量。

2. 可以有更多的 Runner 吗？

有些工作只要可以启动 Docker 就可以完成对应的工作，建立执行 Docker 的 Runner 在这两年是相对简单的，但是还是可能发生在工作伫列等待被执行的工作数量比可以启动 Docker 来执行工作的 Runner 还多，造成工作伫列待执行工作排队等待的情境。

这时候就该思考，怎麽让这样的 Runner 数量可以再增加，以加速流水线完成的速度。

3. Runner Server 可以同步执行 Runner 吗？

在安装 Runner Server 时，有一些参数是重要的，像是 concurrent，代表着 Runner Server 同时可以执行工作的 Runner 数量，这时候就必须要注意执行 Runner Server 是否如环境的特质设置了对等可负担的同时执行数量，Runner Server 可以同时负担的 Runner 增加了，可以工作的 Runner 自然也会增加。

总结

在一开始谈到流水线加速的三要素，分别是：工作少做点、事情做快点、做事的多一点，其用来成为工作流程流水线加速的思考角度，用在管控关卡及工作被执行的 .gitlab-ci.yml 可以往怎麽让工作少做点思考，用在工作伫列管理上，则可以用怎麽让帮忙做事情的可以多一点思考。

接下来将继续谈谈，怎麽让事情可以做快一点，我是墨嗓(陈佑竹)，期待这系列的文章能够让人有些帮助。