1. Pipeline 概述：CI/CD 概念、Pipeline 价值、常见工具对比

1.1 先说清楚：CI/CD 到底是什么？

CI/CD 这四个字母，我见不少人能背出来，但真要问“持续集成和持续交付到底差在哪”，十有八九会卡壳。

说白了，持续集成（CI） 就是“代码一推送，自动帮你编译、跑测试、检查代码规范”。它的核心目标是 —— 尽早发现集成问题。你想想看，十几个人同时改同一个项目，最怕的就是合并时冲突一堆，或者改坏别人的逻辑。CI 就是让机器替你盯住这些事。

持续交付（CD） 则是“每次通过 CI 的代码，都能一键部署到类生产环境”。它强调可发布性 —— 不是已经发布，而是随时可以发布。

持续部署 更进一步：只要 CI 通过，自动推送到生产环境。这一步对测试覆盖率和监控要求特别高。我自己的经验是，大部分团队做到“持续交付”就已经够了，真正敢做“持续部署”的，往往是基础设施非常成熟的团队。

1.2 为什么非得搞 Pipeline？

没 Pipeline 的时候，团队是怎么工作的？

1. 开发写完代码，手动打包。
2. 手动传到测试服务器，可能还要改配置。
3. 测试跑完，再手动部署上线。

听起来也没什么，对吧？但我在项目里遇到过这种情况：上线前发现少了个依赖包，因为本地环境和线上不一致；还有一次测试同学忘了更新数据库迁移脚本，导致回滚花了两小时……这些坑，说白了都是人为操作的不确定性带来的。

Pipeline 的价值就三点：

• 自动化 —— 把重复的编译、测试、部署交给机器，人腾出手做更重要的事。
• 可复现 —— 每次构建环境一致，不会出现“在我电脑上能跑啊”。
• 反馈快 —— 提交后几分钟内就能知道代码有没有问题，不用等第二天测试报告。

1.3 常见工具对比 —— 我用过哪几个？

工具这东西，没有绝对好坏，就看团队习惯和项目规模。我先后在三个不同规模的团队用过 Jenkins、GitLab CI 和 GitHub Actions，简单说说感受。

举个例子，一个最简单的 GitLab CI 配置文件长这样：

stages:
  - build
  - test

build-job:
  stage: build
  script:
    - make build

test-job:
  stage: test
  script:
    - make test

是不是很直观？

Jenkins 的声明式 Pipeline 写法也不复杂：

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'make build'
            }
        }
        stage('Test') {
            steps {
                sh 'make test'
            }
        }
    }
}

嗯，这里要注意：Jenkins 的 Groovy 语法灵活，但也容易写出“脚本地狱”。我曾经见过一个 Jenkinsfile 写了 600 行，维护起来很痛苦。所以现在我建议：能用 YAML 就优先用 YAML，可读性好太多了。

1.4 Pipeline 的整体结构 —— 一张图看懂

为了让你有个整体印象，我把 CI/CD Pipeline 的核心流程画了出来。它基本覆盖了从代码提交到部署的全链条。

1.5 选型建议 —— 我的一点心得

• 初创团队 / 小项目：GitLab CI 或 GitHub Actions 直接拿来用，零运维成本。我建议优先用 GitHub Actions，因为生态好，市场上有大量现成的 action 可以复用。
• 中型团队（10-50人）：如果已经在用 GitLab，继续用 GitLab CI 最省心；如果需要自建，CircleCI 在构建并行度上体验很好。
• 大型企业 / 合规需求：Jenkins 依然是主力，尤其是需要自定义插件或对接内部老旧系统时。不过要做好 Jenkinsfile 的模版化管理，否则容易失控。