1. CI/CD 调度平台概述

在 CI/CD 流水线中，调度平台是连接代码提交、构建、测试、部署等环节的“中枢神经系统”。它负责解析流水线定义、分配执行资源、触发任务、收集状态并驱动整个交付流程。选择一个合适的调度平台，直接影响流水线的可维护性、扩展性和故障恢复能力。

1.1 调度平台在 CI/CD 流水线中的核心作用

调度平台承担以下四个关键职责：

1. 流水线编排：将 CI/CD 流程定义为 DAG（有向无环图），管理阶段依赖与并行关系。
2. 资源分配：为每个任务分配执行节点（容器、虚拟机、物理机），并管理并发配额。
3. 状态追踪：记录每个阶段、每个任务的执行状态（Pending、Running、Success、Failed、Skipped）。
4. 事件驱动：响应 Git 推送、PR 合并、定时触发、外部 Webhook 等事件，自动启动流水线。

1.2 常见调度平台对比

当前业界主流的 CI/CD 调度平台各有侧重，下表从调度模型、适用场景、扩展性、学习成本四个维度进行对比：

1.3 各平台调度模型详解

1.3.1 Jenkins — Master/Agent 队列模型

Jenkins 采用经典的 Master/Agent 架构。Master 负责调度决策、存储配置和展示 UI；Agent 负责实际执行任务。任务以“队列”形式等待 Agent 资源，支持标签匹配和并发控制。

// Jenkins Pipeline 示例：声明式流水线
pipeline {
    agent { label 'linux && docker' }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            parallel {
                stage('Unit Test') {
                    steps { sh 'mvn test' }
                }
                stage('Integration Test') {
                    steps { sh 'mvn verify' }
                }
            }
        }
        stage('Deploy') {
            steps {
                sh 'kubectl apply -f deployment.yaml'
            }
        }
    }
}

1.3.2 GitLab CI — YAML 声明式 + Runner 池

GitLab CI 将流水线定义直接放在仓库根目录的 .gitlab-ci.yml 文件中。调度由 GitLab 服务端控制，Runner 可以注册为共享、分组或特定项目。支持自动扩缩（Kubernetes Runner 或 Docker Machine Runner）。

# .gitlab-ci.yml 示例
stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  image: maven:3.8-openjdk-11
  script:
    - mvn clean package
  artifacts:
    paths:
      - target/*.jar

test-job:
  stage: test
  image: maven:3.8-openjdk-11
  script:
    - mvn test

deploy-job:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl apply -f deployment.yaml
  only:
    - main

1.3.3 Argo Workflows — Kubernetes 原生 DAG

Argo Workflows 将每个流水线步骤定义为 Kubernetes Job 或 Pod，通过 CRD（Custom Resource Definition）管理 DAG 依赖。调度器直接与 K8s API 交互，支持步骤级资源请求、重试策略和并行度控制。

# Argo Workflow 示例（YAML）
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: ci-pipeline-
spec:
  entrypoint: main
  templates:
  - name: main
    dag:
      tasks:
      - name: build
        template: build-step
      - name: test
        template: test-step
        dependencies: [build]
      - name: deploy
        template: deploy-step
        dependencies: [test]
  - name: build-step
    container:
      image: maven:3.8-openjdk-11
      command: [mvn, clean, package]
  - name: test-step
    container:
      image: maven:3.8-openjdk-11
      command: [mvn, test]
  - name: deploy-step
    container:
      image: bitnami/kubectl:latest
      command: [kubectl, apply, -f, deployment.yaml]

1.3.4 Airflow — DAG 调度器 + 执行器

Airflow 使用 Python 代码定义 DAG，调度器定期扫描 DAG 文件并触发任务实例。执行器支持 SequentialExecutor、LocalExecutor、CeleryExecutor 和 KubernetesExecutor。Airflow 的调度能力最强，支持复杂的依赖、回填和 SLA 监控。

# Airflow DAG 示例（Python）
from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime, timedelta

default_args = {
    'owner': 'devops',
    'depends_on_past': False,
    'start_date': datetime(2024, 1, 1),
    'retries': 1,
    'retry_delay': timedelta(minutes=5),
}

with DAG(
    'ci_cd_pipeline',
    default_args=default_args,
    schedule_interval='@daily',
    catchup=False,
) as dag:

    build = BashOperator(
        task_id='build',
        bash_command='mvn clean package',
    )

    test = BashOperator(
        task_id='test',
        bash_command='mvn test',
    )

    deploy = BashOperator(
        task_id='deploy',
        bash_command='kubectl apply -f deployment.yaml',
    )

    build >> test >> deploy

1.4 调度平台选型决策树

在实际项目中，可以按照以下决策路径快速锁定目标平台：

• 基础设施是 K8s 集群吗？
  • 是 → 流水线以容器化任务为主 → Argo Workflows
  • 否 → 继续下一步
• 代码仓库使用 GitLab 吗？
  • 是 → 团队规模 50 人以下 → GitLab CI
  • 否 → 继续下一步
• 需要复杂的 DAG 依赖和定时调度？
  • 是 → 数据管道/ETL 场景 → Airflow
  • 否 → 传统企业、多语言、多 Agent → Jenkins

1.5 本章小结