4道数学题，求解极狐GitLab CI 流水线｜第4题：合并列车

news2024/11/25 20:15:43

本文来自：

武让极狐GitLab 高级解决方案架构师

💡 极狐GitLab CI 依靠其一体化、轻量化、声明式、开箱即用的特性，在开发者群体中的使用率越来越高，在国内企业中仅次于 Jenkins ，排在第二位。

极狐GitLab 流水线有 4 种不同类型，分别是：

有向无环图流水线

父子流水线

多项目流水线

合并列车

但仅靠这些流水线类型名称和官方描述，我们很难理解其意义和用途。因此，作者结合众多用户反馈和自身实践，简明扼要 “重新定义” 了这些流水线类型，并通过 3 篇连载文章为您解答，帮助您掌握极狐GitLab 流水线。

【前文回顾】

1. 🔗有向无环图流水线

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 种用法。

1. 合并请求流水线

回到上面那张图，假设这个项目的流水线脚本是：

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 中运行时，则该流水线称为合并请求流水线。

2. 合并结果流水线

接着上文的逻辑继续，从 test 分支合并到 main 分支，如果 test 分支的合并请求流水线跑通了，那只能说明 test 分支的代码可能没问题，并不能说明合并到 main 分支后的代码或者流水线没问题。

因为基于多分支的开发是同步进行的，假如有人已经向 main 分支提交了一些修改，虽然代码上可能没冲突，但运行逻辑上可能会产生一些影响。这时候可能会出现 MR 被执行合并后，目标分支流水线跑不通，需要进行回退或调试，从而影响其他人的情况。

很显然我们不希望这样的情况产生，所以极狐GitLab 为了解决这个问题，提供了 “合并结果流水线” 功能，可在项目中开启。需要注意的是这个功能属于极狐GitLab 专业版及以上版本功能，免费版不提供该功能。

当开启 “合并结果流水线” 时，极狐GitLab 会在源分支的流水线任务中，本地模拟将源分支合并到目标分支（不会影响到服务端），然后再运行流水线，这样就能一定程度上实现 “预测未来” 的效果，从而避免或降低合并后流水线跑不通的情况。并且在 MR 中，极狐GitLab 会标识出来源分支的流水线是 “合并结果流水线”。

所以：

在合并请求 MR 中，模拟将源分支合并到目标分支，然后再运行流水线，称为合并结果流水线。

3. 合并列车

书接上回，虽然合并结果流水线实现了 “预测未来”，但这个预测是短暂的。因为即便合并结果流水线运行成功，还需要有权限的用户执行合并动作，如果忘记执行合并或者拖了很久的时间才执行合并，这中间就又产生时间差了，预测也就不准了。所以极狐GitLab 祭出了大招，就是 Merge Trains 合并列车。

问题解答

问题 4

假设现在有3个开发人员分别在 feature1、feature2、feature3 分支下进行开发，分别提交了合并请求 MR1、MR2、MR3，彼此之间可能有代码冲突或潜在的功能影响，若在相近或同一时间内进行合并，如何高效率进行合并并尽可能避免合并后的冲突以及流水线失败。

其实这就是系统架构中常见的高并发问题，只不过在 DevOps 中，如果进行协同开发的人比较多、MR 数量较多、流水线运行的频率较快也会出现类似问题。而合并列车就像一个消息队列，开发人员就是生产者，消息就是合并请求 MR，合并列车将并发生产的 MR 收集起来进行排队，然后转成串行任务并自动进行消费（合并），无法消费的任务就踢出，从而实现高效率合并并降低冲突和失败概率。如下图所示，是合并请求流水线、合并结果流水线、合并列车的运行逻辑视图，也是它们之间的区别，更是合并列车的演进历程。