持续集成流水线基础：概念、阶段与工具

各位好，我是老张。在CI/CD这个领域摸爬滚打了十来年，今天跟大伙聊聊流水线的基础。

很多团队刚开始搞CI的时候，总喜欢把“流水线”这个词挂嘴边，但真问起来，什么是流水线？为什么要有阶段？用什么工具？就说不清楚了。我见过不少项目，上来就配一个巨大的Jenkins job，里面塞了编译、测试、打包、部署，所有事情挤在一起，一跑就是半小时。结果一失败，排查起来累得半死。

说白了，流水线就是一种自动化的工作流。它把软件的构建、测试、部署等操作，按照一定的顺序和规则串起来。每个环节都是一个独立的任务，跑完一个才能进下一个。这和工厂的生产线一个道理——你不能在没拧螺丝之前就把轮子装上，对吧？

1. 流水线的基本概念

流水线也叫Pipeline。它定义了一系列的“阶段（Stage）”和“任务（Job）”，每个阶段里可以有一个或多个并行执行的任务。

举个例子：

代码提交 → 编译 → 单元测试 → 集成测试 → 打包 → 部署到测试环境

这就是一条最简单的持续集成流水线。但现实中，我们会根据需要增加更多环节，比如静态代码扫描、安全漏洞检查、性能测试等等。

2. 为什么要划分阶段？

你想想看，如果没有阶段划分，所有任务揉在一起，会出现什么问题？

• 问题定位困难： 一个步骤失败，你不知道是编译崩了，还是测试挂了。
• 资源浪费： 有些任务必须依赖前一个任务的结果（比如必须编译通过才能跑测试），如果没分阶段，那可能先启动了一堆不必要的任务。
• 执行效率低： 阶段划分后，可以并行执行互相独立的任务。比如单元测试和代码扫描可以同时跑。

我在某互联网公司做咨询的时候，发现他们的流水线只有一个阶段：所有任务顺序执行。我说：“你们这哪是流水线，分明是单行道。”后来改成三阶段：第一段编译+静态扫描，第二段单元测试+集成测试，第三段打包+部署。效率提升了一倍。

3. 常见的阶段划分方式

虽然没有标准答案，但业界比较通用的划分方式可以分成以下几大类。我用一个表格来展示：

嗯，这里有个要点：阶段划分的粒度不是越细越好。我曾经在一个项目里把流水线分了20个阶段，结果光阶段间的状态同步就消耗了大量时间。后来我建议合并成5个阶段，反而跑得更快。要根据团队规模和项目复杂度来调整。

4. 核心概念：Stage 与 Job

大多数CI工具都支持两个基本概念：Stage（阶段） 和 Job（任务）。

• Stage：逻辑上的一组任务，同一Stage内的Job可以并行执行。
• Job：实际执行的最小工作单元，比如运行一条命令或一个脚本。

举个例子：

stages:
  - compile
  - test
  - deploy

compile_job:
  stage: compile
  script: make all

unit_test_job:
  stage: test
  script: make test

integration_test_job:
  stage: test
  script: make integration-test

deploy_job:
  stage: deploy
  script: ./deploy.sh

上面这个例子里，stage=test有两个job，它们是并行执行的。只有在test阶段的所有job都成功之后，才会进入deploy阶段。这叫“门禁机制”。

5. 常见工具介绍

工具这东西，没有最好的，只有最合适的。我这些年用过Jenkins、GitLab CI、GitHub Actions、CircleCI、Drone……每个都有自己的脾气。

5.1 Jenkins

老大哥了。从2005年左右开始流行，到现在依然有大量的企业用户。核心特点如下：

• 可扩展性极强： 上千个插件，几乎能对接任何系统。
• Pipeline as Code： 支持Jenkinsfile，写起来类似脚本。我习惯用Declarative Pipeline，语法清晰。
• Master/Agent架构： 可以动态扩展构建节点。

// Jenkinsfile 示例
pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                sh 'make'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
                sh 'make test'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
                sh './deploy.sh'
            }
        }
    }
}

5.2 GitLab CI

GitLab CI是和GitLab代码仓库深度整合的。它的最大优点是：不用单独搭服务器，直接在.gitlab-ci.yml里配置就行。

• Runner机制： 可以共享Runner、特定Runner、自动扩展Runner。
• 与代码仓库天然联动： 每次Push、Merge Request都可以触发流水线。
• 阶段并行非常方便： 支持needs关键字实现更灵活的依赖关系。

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

build-job:
  stage: build
  script:
    - echo "Building..."
    - make build

test-job:
  stage: test
  script:
    - echo "Testing..."
    - make test

deploy-job:
  stage: deploy
  script:
    - echo "Deploying..."
    - ./deploy.sh

我个人特别喜欢GitLab CI的一点是：它支持自动合并请求的流水线状态。比如你要求MR必须通过流水线才能合并，这个配置很简单。我曾在团队里用这个规则，有效减少了坏代码合入主分支的情况。

5.3 其他工具

• GitHub Actions： 和GitHub CI类似，生态很丰富，Marketplace有各种现成的Action。
• CircleCI： 强调速度和缓存，支持并行和SSH调试。
• Drone： 容器化原生，轻量级，适合云原生团队。
• Jenkins X： 针对Kubernetes的CI/CD工具，但学习曲线比较陡。

6. 核心概念关系图

下面我用一张SVG图来展示流水线的基础构成，方便你理解Stage、Job、并行、依赖等概念之间的关系。

7. 总结一下

说来说去，流水线的核心就三样东西：

• 阶段：控制流程的大粒度分割
• 任务：实际执行的原子动作
• 工具：帮你把想法落地的平台

我在带团队的时候，经常强调一句话：流水线是代码的一种，需要像维护项目代码一样维护它。版本控制、重复使用、模块化——这些原则同样适用。