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

有向无环图流水线

父子流水线

多项目流水线

合并列车

事实上,仅靠这些流水线类型名称和官方描述,我们很难理解其意义和用途。

因此,作者结合众多用户反馈和自身实践,简明扼要 “重新定义” 了这些流水线类型:

  • 有向无环流水线,是一个数学题
  • 父子流水线,是一个判断题+选择题
  • 多项目流水线,是一个排列组合题
  • 合并列车,需要追溯其起源,弄清楚合并请求流水线、合并结果流水线合并列车

何以言之?接下来,我们将通过 3 篇连载文章为您解答,帮助您掌握极狐GitLab CI 流水线。

本文为第1篇——有向无环图流水线 ,enjoy~

有向无环图流水线 DAG Pipelines


1. 官方定义

DAG Pipelines 全称是 Directed Acyclic Graph Pipelines,即有向无环图流水线,官方定义和介绍如下:

  • 有向无环图可以在 CI/CD 流水线上下文中,用于在作业之间建立关系,以便以最快的方式执行,无论阶段如何设置;
  • 例如,您可能拥有作为主要项目的一部分而构建的特定工具或单独网站。使用 DAG,您可以指定这些作业之间的关系,系统会尽快执行作业,而不是等待每个阶段完成。

并附上了一个不明觉厉的图:

gitlab 流水线阻塞_ci/cd

相信这段介绍已经击败了 95% 的初学者,那 DAG 流水线到底是什么?它用在什么场景解决什么样的问题?

2. 重新定义

DAG 流水线解决一个数学题


主要功能

  • 消除木桶效应,降低构建时间,提高构建效率;
  • 对流水线 Job 进行编排。

这段介绍相对比较简洁了,但要理解 DAG 流水线,还需要展开来看看这个数学题是什么,以及 DAG 是怎么解决问题的。

展开这个问题前,有些基础概念比如 Runner、Stage、Job 就不再复述了,如果对这些概念不了解,建议先学习极狐GitLab CI 入门知识,可以参考:

  • GitLab CI/CD 入门 | 极狐GitLab
  • CI/CD从入门到实践:yml语法、常用变量、Runner安装配置

3. 问题解答

问题1-1

假设有一个跨平台项目,它通过极狐GitLab CI 分别完成 Android、iOS、PC 三个平台的构建、测试和打包。流水线的 Stage 和 Job 如下所示,Job 中标识了该 Job 执行所需时间。忽略所有 Job 的启动时间,问 PC 平台打包需多长时间?Android 平台打包需多长时间?

gitlab 流水线阻塞_ci/cd_02

需要注意,极狐GitLab CI 中,默认每个 Stage 中,所有 Job 都执行完成才能执行下一个 Stage。即 build 需要等这个 Stage 中用时最久的 Job 即 build_ios 执行完成后才能执行 test,也就是需要 60s。

所以:

  • PC 平台打包用时=60s+30s+40s=130s;
  • Android 平台打包用时=60s+30s+40s=130s。

这就是所谓 “木桶效应”,理论上 PC 平台的打包与 iOS 和 Android 平台没有关系,但却要等待它们相关 Job 执行,被严重拖了后腿。

为了解决这个问题,就可以使用 DAG 流水线。它的原理和使用方式非常简单,通过给 Job 加上 needs 关键字,将 Job 的依赖关系进行编排,比如:

build_pc_dll
    stage: build
    script:
        - echo 'pc dll building'
        
build_pc
    stage: build
    script:
        - echo 'pc building'

build_android
    stage: build
    script:
        - echo 'android building'

test_pc:
    stage: test
    needs: [build_pc, build_pc_dll]
    script:
        - echo 'pc testing'
        
test_android:
    stage: test
    needs: [build_android]
    script:
        - echo 'android testing'
        
pkg_pc:
    stage: package
    needs: [test_pc]
    script:
        - echo 'pc packaging'

pkg_android:
    stage: package
    needs: [test_android]
    script:
        - echo 'android packaging'

这样 PC 平台打包就仅与 PC 平台的构建和测试 Job 相关,与其他 Job 无关了,也不需要等待其他 Job 执行。当然,这个例子为了更丰富的体现 DAG 流水线的特性,又增加了一个 build_pc_dll Job,并且让 test_pc 同时依赖 build_pc 和 build_pc_dll 。

问题1-2

使用 DAG 流水线后,PC 平台打包需多长时间?Android平台打包需多长时间?

gitlab 流水线阻塞_ci/cd_03

解答:

  • PC 平台打包用时=40s+30s+30s=100s;
  • Android 平台打包用时=30s+20s+40s=90s;
  • iOS 平台打包用时=60+15+20=95s;
  • 流水线总用时=Max(100, 90, 95)=100s。

可以看到,不论是各平台最终 Job 的用时还是流水线的总用时都降低了,这也就是为什么说 DAG 流水线是解决一个数学题,以及它是如何消除木桶效应、降低构建时间、提高构建效率以及如何实现对流水线 Job 进行编排的

最后,我们可以在极狐GitLab 的 “CI/CD 流水线”,选择指定流水线,然后点击 “依赖关系图”,就可以看到上文中这张不明觉厉的图了。这时候相信大家也能更好的理解这张图,更好的理解 DAG 流水线了。

gitlab 流水线阻塞_ci/cd_04

4. 总结 DAG 流水线使用场景

1.  流水线中有多个并行业务逻辑:比如 Monorepo(一个代码仓库中有多个模块/包)中多个模块同时构建、测试、打包,或类似上文中的跨平台编译打包,这些业务彼此之间相对独立。可以使用 DAG 流水线降低构建时间,提高构建效率。

2.  流水线 Job 有依赖关系:比如 Monorepo 中构建模块 C 需要模块 A 和模块 B 的构建产物,可以使用 DAG 流水线的 needs 关键字对这些 Job 进行编排。