本文来自：
武让 极狐GitLab 高级解决方案架构师
💡 极狐GitLab CI 依附其一体化、轻量化、申明式、开箱即用的个性，在开发者群体中的使用率越来越高，在国内企业中仅次于 Jenkins ，排在第二位。
极狐GitLab 流水线有 4 种不同类型，别离是：
有向无环图流水线
父子流水线
多我的项目流水线
合并列车
但仅靠这些流水线类型名称和官网形容，咱们很难了解其意义和用处。因而，作者联合泛滥用户反馈和本身实际，简明扼要 “从新定义” 了这些流水线类型，并通过 3 篇连载文章为您解答，帮忙您把握极狐GitLab 流水线。
【前文回顾】
- 🔗有向无环图流水线
2. 🔗父子流水线+多我的项目流水线
本文是最初一篇——合并列车 ，enjoy～
合并列车 Merge Trains
官网定义
Merge Trains 即合并队列或者叫合并列车，我记得当初可能得花了 2、3 蠢才彻底弄明确这货色到底是干嘛的，先看看官网定义：
应用合并队列对合并申请进行排队，并在将它们合并到指标分支之前验证它们的更改是否能够协同工作。
在频繁合并到默认分支的我的项目中，不同合并申请的更改可能会互相抵触。合并后果流水线确保更改实用于默认分支中的内容，但不适用于其他人同时合并的内容。
懵没懵？GitLab Inc 甚至写了一整篇 Blog 来介绍 Merge Trains 以及 Merge Trains 工作流，详见：《How starting merge trains improve efficiency for DevOps》，内容很丰盛，然而我真的没看懂。
通过一番折腾，我发现要想了解 Merge Trains，得先理解它的前世今生。
从新定义
相熟极狐GitLab CI 的敌人肯定晓得在极狐GitLab 的合并申请（MR）中是能够看到与这个 MR 相干的流水线的运行状况，如下图所示，共有两局部流水线，其中：
- 下面的流水线是发动 MR 后始终到 MR 合并之前，如果源分支 test 有代码提交就会运行流水线，也就是流水线运行在源分支上；
- 上面的流水线是 MR 被执行合并后，在指标分支
main上运行流水线：
这个逻辑是说，当发动一个 MR 时，假如从 test 分支合并到 main 分支，那么极狐GitLab 首先会在 test 分支下跑流水线，只有当 test 分支的流水线跑胜利时，才阐明至多 test 分支的代码是跑得通的，也意味着能够合并到 main 分支。如果 test 分支的流水线都跑不通，那么合并到 main 分支后会导致 main 分支的代码也无奈失常执行，这就失去了多分支协同开发的意义。
当 test 分支被胜利合并到 main 分支后，极狐GitLab会在 main 分支下再跑一次流水线，用来验证合并后的代码是否可能跑通流水线，或者间接执行部署工作。
基于这个逻辑，在合并申请的根底上，极狐GitLab CI 又延长出 3 种用法。
合并申请流水线
回到下面那张图，假如这个我的项目的流水线脚本是：
stages:
- build
- test
- deploy
build-job:
stage: build
script:
- echo "Compiling code..."
- echo "Compile complete."
unit-test-job:
stage: test
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 6
- echo "Code coverage is 90%"
deploy-job:
stage: deploy
script:
- echo "Deploying application..."
- echo "Application successfully deployed."那么如果在这个我的项目中发动一个 MR，从 test 分支合并到 main 分支，首先会在 test 分支下运行下面的流水线。
但假如开发人员仅仅想在 test 分支下运行 build 和 test 阶段的工作，不心愿执行 deploy 阶段，这时候就须要用到 if 或 only 关键字，比方：
stages:
- build
- test
- deploy
build-job:
stage: build
# 仅在MR中运行
only:
- merge_requests
script:
- echo "Compiling code..."
- echo "Compile complete."
unit-test-job:
stage: test
# 仅在MR中运行
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
script:
- echo "Running unit tests... This will take about 60 seconds."
- sleep 6
- echo "Code coverage is 90%"
deploy-job:
stage: deploy
script:
- echo "Deploying application..."
- echo "Application successfully deployed."这样设置之后，当开发人员向 test 分支提交代码时，如果没有基于 test 分支的 MR，那么流水线脚本中的所有工作都会执行；如果有基于 test 分支的MR，那么只在 test 分支下执行流水线脚本中的 build、test 阶段的工作，不会执行 deploy 的工作。并且在 MR 中，极狐GitLab 会标识出起源分支的流水线是 “合并申请流水线”。
所以：
当一条流水线中的某些 Job 仅在合并申请 MR 中运行时，则该流水线称为合并申请流水线。
合并后果流水线
接着上文的逻辑持续，从 test 分支合并到 main 分支，如果 test 分支的合并申请流水线跑通了，那只能阐明 test 分支的代码可能没问题，并不能阐明合并到 main 分支后的代码或者流水线没问题。
因为基于多分支的开发是同步进行的，如果有人曾经向 main 分支提交了一些批改，尽管代码上可能没抵触，但运行逻辑上可能会产生一些影响。这时候可能会呈现 MR 被执行合并后，指标分支流水线跑不通，须要进行回退或调试，从而影响其他人的状况。
很显然咱们不心愿这样的状况产生，所以极狐GitLab 为了解决这个问题，提供了 “合并后果流水线” 性能，可在我的项目中开启。须要留神的是这个性能属于极狐GitLab 专业版及以上版本性能，免费版不提供该性能。
当开启 “合并后果流水线” 时，极狐GitLab 会在源分支的流水线工作中，本地模仿将源分支合并到指标分支（不会影响到服务端），而后再运行流水线，这样就能肯定水平上实现 “预测将来” 的成果，从而防止或升高合并后流水线跑不通的状况。并且在 MR 中，极狐GitLab 会标识出起源分支的流水线是 “合并后果流水线”。
所以：
在合并申请 MR 中，模仿将源分支合并到指标分支，而后再运行流水线，称为合并后果流水线。
合并列车
书接上回，尽管合并后果流水线实现了 “预测将来”，但这个预测是短暂的。因为即使合并后果流水线运行胜利，还须要有权限的用户执行合并动作，如果遗记执行合并或者拖了很久的工夫才执行合并，这两头就又产生时间差了，预测也就不准了。所以极狐GitLab 祭出了大招，就是 Merge Trains 合并列车。
问题解答
问题 4
假如当初有3个开发人员别离在 feature1、feature2、feature3 分支下进行开发，别离提交了合并申请 MR1、MR2、MR3，彼此之间可能有代码抵触或潜在的性能影响，若在相近或同一时间内进行合并，如何高效率进行合并并尽可能防止合并后的抵触以及流水线失败。
其实这就是零碎架构中常见的高并发问题，只不过在 DevOps 中，如果进行协同开发的人比拟多、MR 数量较多、流水线运行的频率较快也会呈现相似问题。而合并列车就像一个音讯队列，开发人员就是生产者，音讯就是合并申请 MR，合并列车将并发生产的 MR 收集起来进行排队，而后转成串行工作并主动进行生产（合并），无奈生产的工作就踢出，从而实现高效率合并并升高抵触和失败概率。如下图所示，是合并申请流水线、合并后果流水线、合并列车的运行逻辑视图，也是它们之间的区别，更是合并列车的演进历程。
合并列车是基于合并后果流水线的，也是极狐GitLab 专业版及以上版本的性能，也须要在我的项目中开启。
所以：
将多个 MR 进行排队，一一运行合并后果流水线，运行通过就主动合并，运行不通过就踢出队列，这样的流水线称为合并列车。
最初用一张图比照 MR 中的三种流水线，须要阐明的是合并后果流水线在实践中用到的更多，毕竟大部分企业和研发团队的协同效率和要求不会达到那么高，DevOps 建设也能够遵循架构设计的三准则：简略、适宜、演进。
🌟 至此，极狐GitLab 4 种流水线介绍结束，心愿以上内容对您有帮忙！
欢送关注极狐GitLab ，一起开启研发效力晋升之旅！
发表回复