Day27 - GitLab CI 如何让工作流程流水线跑快一点？之一 从 .gitlab-ci.yml 大部分解

在专案过程中，透过 GitLab CI 建立流水线，让研发过程中如编译、测试、打包、部署等工作都得以顺利的自动化，除了让开发变得更有效率，也在无形之中，形成了保护专案的门神。提到效率的，会希望好还要更好，如果 GitLab CI 的流水线可以跑得更快一点，除了让研发等待的时间少了，自然也会省下一些资源。

接下来的篇幅，将讨论怎麽让 GitLab CI 的流水线进行得更快一些，在正式开始讨论之前，看到这篇文的朋友，可以稍微想一下，当一个 GitLab 上的工作流程流水线被启动时，一直到整个流水线的工作结束，期间会有哪些动作呢？或者是，会有哪些地方必须工作呢？

底下将透过工作的拆解来初步了解流水线期间发生了什麽事情。

一、从 .gitlab-ci.yml 到工作伫列 (Queue)

当 GitLab CI 的流水线工作启动之後，GitLab CI Server 端会解析 .gitlab-ci.yml 的描述，依据描述部署出一条流水线，在这时候，流水线上每道关卡、每到关卡上的规划的每一个工作都已经确立好它们的位置了。

接下来 GitLab CI Server 会将已经可以被执行的工作，依序放到工作伫列(Queue)上，等待工作被执行，待等待被执行的工作们回报它们的工作状况後，GitLab CI Server 才根据 .gitlab-ci.yml 的描述，决定後续关卡上等待被执行工作是否派送到工作伫列等待被执行。当然也有可能已经没有下一关卡，则最後一个被执行完的工作所回报的工作成果，就是这条流水线执行的最终结果。

二、从工作伫列(Queue)到 GitLab Runner

当等待被执行的工作们被排入 GitLab CI 的工作伫列上之後，与目前的 GitLab CI Server 有合作关系的且空闲着的 GitLab Runner 们，就会依据自身的工作执行能力来工作伫列询问，是否有适合自己可以执行的工作。

GitLab CI Server 在此，就担任着工作媒合者的角色，把等待被执行的工作发包给宣称自己适合执行该工作的 GitLab Runner 拿回去执行，并且等待这些 Runner 回报工作状况及工作成果。

三、Runner 取得工作後怎麽作事情？

GitLab Runner 在取得可以执行的工作後，便会在自己可以管控的区域中开始依据自己的能力初始化执行工作的环境，接着依据取得的工作描述布置工作环境，而後正式开始执行这个工作。

执行的过程中随时跟 GitLab CI Server 回报目前的进度状况，变且根据工作的描述产出工作成品，并交回 GitLab CI Server 上留存，除了交出的诚品外，GitLab Runner 自己也会根据工作描述上所说的，留下可以暂存的产物，待下次取得可以使用这份暂存的工作，再次取出来使用，待这些工作都完成後，正式回应 GitLab CI Server 工作完成。

当然期间可能会因为一些工作环境等因素而造成工作执行失败，这部分也会回应给 GitLab CI Server 让 Server 判断後续的工作分派该如何进行。

四、打个比方

如上面的三个段落，大致上把 GitLab CI 开始启动一个流水线，一直到流水线完成可能遇到的情境做了一次交代，但文字有点多，内容有点烦杂，所以这边想了一个古代镖局护镖的剧情来比喻 GitLab CI 的流程。

这部分可以想像小说里头的镖局护镖剧情，GitLab CI 的工作们就像是「镖」；业主心里有些想法，就像是 .gitlab-ci.yml 定义着这个镖该分几次运送、每次运送多少「镖」、要送到哪；承接工作的镖局就像是 GitLab CI Server，根据业主的需求逐步的把「镖」公开出来，等待有空的镖师们护镖。

而与镖局有合作关系的镖师们是懂的自己有几两重的，自然只会选择承接的起的镖来护。护「镖」的过程可能很顺利，也可能会遇到一些状况，这些都会一一的跟镖局回报，哪怕是用飞鸽传书。

镖局根据镖师们的护镖成果来决定是否启动业主的下一阶段护镖行动，当其中有一次护镖失败，则可能会导致後续的工作都不能再执行，当然也可能可以继续执行，端看业主当初与镖局谈的合约 (.gitlab-ci.yml)。

总结：

把 GitLab CI Server 与 GitLab Runner 间的工作流程再次的透过文字描述出来，是因为要让流水线执行的更顺畅，必须从工作的每个环节中去着手，去思考它的必要性？思考是不是还有机会更快？接下来也会再根据这些环节逐一去讨论更多细节。

也希望最後一段的的镖局剧情，可以让这些文字有了一点有趣的想像，我是墨嗓(陈佑竹)，期待这系列的文章能够让人有些帮助。