共计 5151 个字符，预计需要花费 13 分钟才能阅读完成。
本文来自：
武让 极狐(GitLab) 高级解决方案架构师
💡 极狐 GitLab CI 依附其 一体化、轻量化、申明式、开箱即用 的个性，在开发者群体中的使用率越来越高，在国内企业中仅次于 Jenkins，排在第二位。
极狐 GitLab 流水线有 4 种不同类型，别离是：
有向无环图流水线
父子流水线
多我的项目流水线
合并列车
但仅靠这些流水线类型名称和官网形容，咱们很难了解其意义和用处。因而，作者联合泛滥用户反馈和本身实际，简明扼要“从新定义”了这些流水线类型，并通过 3 篇连载文章为您解答，帮忙您把握极狐 GitLab 流水线。
第 1 篇分享了🔗有向无环图流水线。
本文是第 2 篇——父子流水线 + 多我的项目流水线，enjoy～
父子流水线 Parent-Child Pipelines
1. 官网定义
Parent-Child Pipelines 即父子流水线，它和 Multi-Project Pipelines 多我的项目流水线都属于上游流水线。所谓上游流水线：
由另一个流水线触发的任何极狐 GitLab CI/CD 流水线。它能够是：
- 一个父子流水线，是与第一个流水线在同一个我的项目（代码库）中触发的上游流水线；
- 多我的项目流水线，是在与第一个流水线不同的我的项目（代码库）中触发的上游流水线。
父子流水线，官网定义和介绍如下：
父流水线是在同一我的项目（代码库）中触发上游流水线的流水线，上游流水线称为子流水线。
- 子流水线依然依据阶段程序执行他们的每个工作，但能够自在地持续他们的阶段，而无需期待父流水线中不相干的工作实现；
- 该配置被拆分为更小的子流水线配置。每个子流水线只蕴含更容易了解的相干步骤，缩小了了解整体配置的认知累赘；
- 导入在子流水线级别实现，缩小了抵触的可能性。
这个解释比 DAG 流水线要容易了解一些，然而咱们仍然能够换一种比拟接地气的形式进行从新形容。
2. 从新定义
父子流水线解决一个 判断题 + 选择题。
次要性能：
- （按条件触发并）执行 同一个我的项目（代码库）中不同 的流水线脚本。
3. 问题解答
接着第 1 篇 有向无环图流水线 中的问题 1 持续，还是那个跨平台我的项目。
问题 2
如果当初 iOS 平台利用有一些 Bug，开发人员仅对 iOS 局部代码进行了批改，而后心愿编译打包 iOS 平台利用并公布上线。但不心愿再次打包 PC 和 Android 平台，浪费时间和资源，怎么办？如果是个通用问题，在 3 个平台上都呈现了，那么批改通用局部代码后还须要同时打包 3 个平台的利用，又该怎么办？这个跨平台我的项目文件目录如下：
- common
- code_files...
- .gitlab-ci.yaml #全副平台构建打包脚本
- android
- code_files...
- .gitlab-ci.yaml #Android 平台构建打包脚本
- ios
- code_files...
- .gitlab-ci.yaml #iOS 平台构建打包脚本
- pc
- code_files...
- .gitlab-ci.yaml #pc 平台构建打包脚本
为了解决这个问题，就须要应用到父子流水线，次要会应用到 rules:is:changes 和 trigger 关键字，用来实现按条件触发，而后执行不同流水线脚本，比方：
stages:
- build
- triggers
android_trigger:
stage: triggers
# 当 android 目录下的文件发生变化时触发
rules:
- if:
changes:
- android/*
# 触发执行 android/.gitlab-ci.yml 脚本
trigger:
include: android/.gitlab-ci.yml
strategy: depend
ios_trigger:
stage: triggers
# 当 ios 目录下的文件发生变化时触发
rules:
- if:
changes:
- ios/*
# 触发执行 ios/.gitlab-ci.yml 脚本
trigger:
include: ios/.gitlab-ci.yml
strategy: depend
pc_trigger:
stage: triggers
# 当 pc 目录下的文件发生变化时触发
rules:
- if:
changes:
- pc/*
# 触发执行 pc/.gitlab-ci.yml 脚本
trigger:
include: pc/.gitlab-ci.yml
strategy: depend
common_build:
stage: build
script:
- echo "common build"
# 当 common 目录下的文件发生变化时触发，执行默认的根目录.gitlab-ci.yml 脚本
rules:
- changes:
- common/*
当批改 iOS 目录文件后，只触发了 ios/.gitlab-ci.yml 脚本的执行。
当批改 common 目录文件或间接手动执行流水线后，触发执行根目录的 .gitlab-ci.yml 脚本，也就是触发所有构建。
当然这个判断题不是必要的，能够在一个失常的 Job 中间接做选择题，比方：
microservice_a:
trigger:
include: path/to/microservice_a.yml
也能够批改判断题的条件，比方应用极狐 GitLab 的变量来进行条件管制：
pc_trigger:
stage: triggers
# 当 PLATFORM 变量的值为 PC 时触发
rules:
- if: $PLATFORM == "PC"
# 触发执行 pc/.gitlab-ci.yml 脚本
trigger:
include: pc/.gitlab-ci.yml
strategy: depend这样就实现了依照条件触发不同的流水线脚本，这也就是说为什么父子流水线是解决一个 判断题 + 选择题 ，以及它是如何（按条件触发并）执行同一个我的项目中不同的流水线脚本 的。
4. 总结父子流水线应用场景
1. 按条件灵便触发并执行一个我的项目中不同的流水线脚本：比方在一个我的项目中，将一个简单的流水线脚本拆分成多个简略的流水线脚本，通过 tigger 关键字组合，实现解耦和升高复杂度。或相似上文中提到的按条件独自执行 Monorepo 中局部模块的构建、测试、打包。
2. 父子流水线 + DAG 流水线：能够将父子流水线与 DAG 流水线联合应用，比方 pc/.gitlab-ci.yml 中仍然应用 DAG 流水线使得 test_pc 依赖 build_pc 和 build_pc_dll。
多我的项目流水线 Multi-Project Pipelines
1. 官网定义
Multi-Project Pipelines 多我的项目流水线，它和父子流水线都属于上游流水线，官网定义和介绍如下：
能够跨多个我的项目（代码库）设置极狐 GitLab CI/CD，以便一个我的项目（代码库）中的流水线能够触发另一个我的项目（代码库）中的流水线。您能够在一个中央可视化整个流水线，包含所有跨我的项目的相互依赖关系。
相熟了父子流水线后，再看多我的项目流水线就比较简单了。它们都是触发上游不同的流水线，只是面向的对象不同，父子流水线面向的是同一个我的项目（代码库），而多我的项目流水线是面向不同的我的项目（代码库），这也决定了它们应用的场景不同。
2. 从新定义
持续用艰深的语言来解释：
多我的项目流水线解决的是 排列组合题。
次要性能：
- 编排并执行 不同的我的项目（代码库）中 的流水线脚本。
回顾上文中的 DAG 流水线和父子流水线，应用的场景大多都是在 Monorepo 模式下，对一个我的项目内的流水线或者 Job 进行编排。而当初架构设计畛域的支流思维还是模块化和微服务，所以不少企业或开发人员还是习惯对我的项目进行拆分，用多个代码库进行治理。在这样的模式下，DAG 和父子流水线应用的机会就绝对较少了，而多我的项目流水线就派上了用场。举例如下：
3. 问题解答
问题 3
假如有个 Web 我的项目，在极狐 GitLab 中建设了一个群组 MyProject 来治理这个我的项目。前端代码放在代码库 MyProject/Frontend 中，后盾代码放在代码库 MyProject/Server 中。测试团队对前端代码编写的 UI 自动化测试脚本放在代码库 MyProject/Frontend-UI-Testing 中，对后盾代码编写的 API 自动化测试脚本放在代码库 MyProject/Server-API-Testing 中。要求部署时先部署后盾代码，再部署前端代码，并同步进行后盾的 API 测试，最初再进行前端的 UI 测试。
应用多我的项目流水线来解决这个问题，仍然要应用 trigger 关键字。因为该问题中，后盾代码的流水线是整个业务链条的终点，所以先看代码库 MyProject/Server 的流水线：
stages:
- build
- test
- deploy
- downstream
# 编译构建
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%"
# 格局校验
lint-test-job:
stage: test
script:
- echo "Linting code... This will take about 10 seconds."
- sleep 1
- echo "No lint issues found."
# 部署工作
deploy-job:
stage: deploy
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
# API 测试
api-test-job:
stage: downstream
# 触发上游流水线
trigger:
project: MyProject/Server-API-Testing
strategy: depend
# 部署前端
deploy-frontend-job:
stage: downstream
# 触发上游流水线
trigger:
project: MyProject/Frontend
strategy: depend以后端我的项目部署胜利后须要执行前端的 UI 测试，所以代码库 MyProject/Frontend 的流水线如下：
stages:
- build
- test
- deploy
- downstream
# 省略 build、test、deploy 脚本
# UI 测试
ui-test-job:
stage: downstream
# 触发上游流水线
trigger:
project: MyProject/Frontend-UI-Testing
strategy: depend
流水线运行成果如下，也就是官网定义中所说的“您能够在一个中央可视化整个流水线，包含所有跨我的项目的相互依赖关系”，但这个性能是属于极狐 GitLab 专业版及以上版本，免费版无奈看到这个成果。
正因为多我的项目流水线可能 编排多个我的项目（代码库）流水线 ，所以说它解决的是一个 排列组合题。
4. 总结多我的项目流水线应用场景
按程序触发并执行不同我的项目的流水线脚本：比方部署后运行自动化测试，或依照肯定的程序部署不同的模块、服务等。
🌟 极狐 GitLab 4 种流水线之“父子流水线 & 多我的项目流水线”暂且搁笔，心愿以上内容对您有帮忙！接下来咱们的连载内容是：
- 合并列车
欢送关注极狐 GitLab，及时“追番”不迷路！
