关于gitlab:4道数学题求解极狐GitLab-CI-流水线|第4题合并列车

36次阅读

共计 3572 个字符,预计需要花费 9 分钟才能阅读完成。

本文来自
武让 极狐 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 种用法。

合并申请流水线

回到下面那张图,假如这个我的项目的流水线脚本是:

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 个开发人员别离在 feature1feature2feature3 分支下进行开发,别离提交了合并申请 MR1、MR2、MR3,彼此之间可能有代码抵触或潜在的性能影响,若在相近或同一时间内进行合并,如何高效率进行合并并尽可能防止合并后的抵触以及流水线失败。

其实这就是零碎架构中常见的高并发问题,只不过在 DevOps 中,如果进行协同开发的人比拟多、MR 数量较多、流水线运行的频率较快也会呈现相似问题。而合并列车就像一个音讯队列,开发人员就是生产者,音讯就是合并申请 MR,合并列车将并发生产的 MR 收集起来进行排队,而后转成 串行工作 主动 进行生产(合并),无奈生产的工作就踢出,从而实现高效率合并并升高抵触和失败概率。如下图所示,是合并申请流水线、合并后果流水线、合并列车的运行逻辑视图,也是它们之间的区别,更是合并列车的演进历程。

合并列车是基于合并后果流水线的,也是极狐 GitLab 专业版及以上版本的性能,也须要在我的项目中开启。

所以:

将多个 MR 进行排队,一一运行合并后果流水线,运行通过就主动合并,运行不通过就踢出队列,这样的流水线称为合并列车。

最初用一张图比照 MR 中的三种流水线,须要阐明的是合并后果流水线在实践中用到的更多,毕竟大部分企业和研发团队的协同效率和要求不会达到那么高,DevOps 建设也能够遵循架构设计的三准则:简略、适宜、演进

🌟 至此,极狐 GitLab 4 种流水线介绍结束,心愿以上内容对您有帮忙!

欢送关注极狐 GitLab,一起开启研发效力晋升之旅!

正文完
 0