CI/CD 入门：持续集成、持续交付、持续部署是什么

很多教程把 CI/CD 说得高深，其实它解决的只有一个问题："每次改代码，都要人肉重复地构建、测试、上传，太累也太容易出错，能不能自动化？" 打个比方：手动发布就像一家快餐店靠老板一个人配菜、颠勺、装盒、送餐；上了 CI/CD，就像给后厨装了流水线——顾客下单（提交代码），机器自动备菜（构建）、质检（测试）、打包（制品）、出餐（部署）。本文讲清 CI 和 CD 的差别、流水线有哪些阶段、主流工具有哪些，并给一条能照抄的示例。

先分清三个词：CI、CD、CD

三个缩写连读会绕晕，拆开看就清楚了：

  • CI（持续集成，Continuous Integration）：频繁把大家的代码合并到主干，每次合并都自动构建并跑测试。目的是尽早发现"你改的和我改的冲突了"。
  • CD（持续交付，Continuous Delivery）：在 CI 之上，保证每次提交都处于"随时可以发布"的状态——测试全过、产物已生成，但是否发布由人决定。
  • CD（持续部署，Continuous Deployment）：再进一步，测试通过后自动发布到生产环境，全程无人审批。

一句话记住：CI 管"测"，交付 CD 管"准备好"，部署 CD 管"直接上线"。风险敏感的业务（电商、金融）多停在"持续交付"；内部工具或低风险网站可以走到"持续部署"。

一条流水线有哪些阶段

一条典型流水线（Pipeline）通常长这样：

  1. 触发：推送到 Git 分支、打 Tag 或定时触发；
  2. 检出（Checkout）：拉取最新代码；
  3. 安装依赖：如 npm install、composer install；
  4. 构建（Build）：编译、打包前端资源；
  5. 测试（Test）：跑单元测试、lint、构建产物检查；
  6. 制品（Artifact）：把可部署的包存起来（如 Docker 镜像）；
  7. 部署（Deploy）：推到测试/预发/生产环境；
  8. 通知：成功或失败时发邮件/Slack/钉钉。

每个阶段失败都会中断流水线并通知你，这就是"问题尽早暴露"的价值。想看你自己的网站怎么套用，可参考网站 CI/CD 流水线搭建。

主流工具对比

工具 托管方式 上手难度 优势 适合
GitHub Actions 云端（GitHub 内置） 低 与仓库零配置集成、生态丰富 GitHub 用户、个人到中型团队
GitLab CI 云端/自托管 中 内置容器注册表、一体化强 GitLab 用户、DevOps 重度
Jenkins 自托管 高 插件极多、可高度定制 已有 Java 生态、复杂流水线

选型建议：代码放哪、就用谁的 CI，别为了"专业"去额外维护一套 Jenkins。GitHub Actions 入门可看GitHub Actions CI/CD 指南；GitLab 场景可看GitLab CI/CD 最佳实践。

一条流水线示例（GitHub Actions）

以"提交代码后自动测试并部署到服务器"为例，.github/workflows/deploy.yml 的核心逻辑如下：

name: CI/CD
on:
  push:
    branches: [main]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
  deploy:
    needs: build-test
    runs-on: ubuntu-latest
    steps:
      - name: SSH 部署
        run: ssh deploy@server "cd /var/www/app && git pull && npm ci && pm2 restart app"

含义：推送到 main 分支后，先跑依赖安装与测试，全绿才通过 SSH 登录服务器拉取代码并重启服务。真实项目里建议把密钥放进 Secrets，并参考GitHub Actions SSH 部署和Docker Compose 生产部署完善。

从零上手 CI/CD 的路径

如果之前完全没用过 CI/CD，建议按下面三步循序渐进，不要一步到位：

  1. 先把构建和测试自动化：把"npm test / php artisan test"这类命令接到 CI 上，让每次提交自动跑测试，先解决"质量"问题。
  2. 再加制品与镜像：测试通过后自动构建产物（或 Docker 镜像）并保存，让"可发布的东西"随时存在。
  3. 最后加自动部署：先部署到测试环境，人工验收通过后，再逐步放开到生产；每个阶段都可以先"手动触发"再转"自动触发"。

还有一个容易忽略的点：流水线本身也是代码，要版本化、要评审。把 .github/workflows 或 .gitlab-ci.yml 当普通代码一样维护，改流水线也要经过测试与代码评审，这样才不会"流水线坏了没人知道"。记住，CI/CD 的价值不在"用了多高级的工具"，而在"每次改动都能被自动、一致地验证与交付"——哪怕只先自动化一个测试命令，也比完全没有强。

常见问题（FAQ）

Q1：CI/CD 和部署是一回事吗？ 不是。部署是"把产物放到生产环境"这一个动作；CI/CD 是把构建、测试、部署串成一条自动化流水线。Q2：小网站有必要上吗？ 单人或小站可以先从"Git 自动拉取"开始；当测试变多、发布变频繁时再上完整 CI/CD。Q3：流水线一直失败怎么办？ 把流水线拆小，先让"构建+测试"跑绿，再逐步加部署阶段，失败时看日志定位是哪一步。Q4：持续部署会不会很危险？ 会。风险高就先停在"持续交付"（人工点发布），配合灰度与回滚再谈自动部署。
Q5：流水线该在哪一层运行？ 用厂商托管的 Runner 最简单；自建 Runner 适合需要内网访问或特定硬件（GPU、构建缓存）的场景，但要自己维护。