GitHub Actions CI/CD流水线配置教程：从零搭建自动测试、构建、部署的实战脚本

开场：今天直接把流水线跑起来

哈喽兄弟们，eccfy 开整！今天我不讲虚的，直接带你把 GitHub Actions CI/CD 流水线从 0 搭起来。OK so，你现在手上如果只有一个仓库，想实现“代码一 push，自动测试、自动构建、自动部署”，那这篇就是你要收藏的。接下来我会像录屏一样，一步一步把屏幕上的配置敲出来，你照着抄就能跑。

先说结论：GitHub Actions 最适合先做 CI，也就是拉代码后自动检查；等 CI 稳了，再加 CD，也就是部署。别一上来就把 deploy 绑死，不然你会在第一天就收获一堆红色失败记录。实战里我见过一个 Node 项目，原本本地测试要 3 分钟，接入 Actions 后每次 PR 自动跑，平均 1 分 40 秒出结果，问题定位速度直接快一截。

第一章：先做最小可用 CI，别上来就整花活

接下来打开你的仓库，在根目录创建 .github/workflows/ci.yml。这个文件就是流水线主角。下面这个模板适合大多数前端、Node、Python 项目，你先把它跑通，再按你的技术栈微调。

name: CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install deps
        run: npm ci

      - name: Run tests
        run: npm test

看屏幕，重点有三个：checkout 拉代码，setup-node 装运行环境，npm ci 做干净安装。为什么不用 npm install？因为 CI 更需要可重复，npm ci 会严格按 lockfile 装包，更稳定。你要是做 Python 项目，就把 Node 那段换成 actions/setup-python 和 pip install -r requirements.txt。

这里我建议你先把“自动测试”跑通，再谈构建镜像、发版、滚动部署。很多人搜“GitHub Actions教程”的时候，一上来就想一条龙，其实最容易卡在权限、环境变量、制品上传这三个点。

第二章：加缓存和构建，速度会明显不一样

OK so，下面进入“Now watch this”环节。把缓存加上后，第二次运行速度会明显缩短，尤其是依赖多的项目。我在一个 300MB 依赖量的前端仓库里测过，第一次跑 4 分 50 秒，开启缓存后第二次降到 2 分 05 秒，差距很直观。

name: Build and Test

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci
      - run: npm run build

如果你想更稳一点，可以把构建产物打包出来，例如 dist、build、Docker 镜像。这里有个非常实用的判断标准：CI 阶段只负责验证，CD 阶段才负责发布。也就是说，测试失败就别部署，构建失败也别硬发。

常见问题我直接帮你点出来：一是分支名写错，main 和 master 搞混；二是 lockfile 没提交，导致缓存命中但依赖版本漂移；三是脚本在本地能跑，CI 里报错，多半是环境变量没带上。你可以在仓库里专门建一个 .env.example，把必须项列清楚，减少“我本地没问题啊”的经典事故。

第三章：从 CI 走到 CD，发布动作要可回滚

接下来是部署。免费/官方路线优先，我建议先从 SSH 部署、GitHub Pages、或容器镜像推送开始，别急着接复杂平台。比如静态站点，你可以直接用 Actions 把构建产物部署到 GitHub Pages；后端服务则常用 SSH 拉取最新镜像或代码再重启服务。下面给你一个最常见的 SSH 部署思路：

name: Deploy

on:
  push:
    tags:
      - 'v*'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /var/www/app
            git pull
            npm ci --omit=dev
            npm run build
            pm2 reload app

这里的核心不是“怎么连上服务器”，而是“怎么保证出问题能退回去”。最稳的做法是：发布前打 tag，比如 v1.2.3，服务器保留上一个版本；如果新版本挂了，直接切回上一个 tag。你要做“GitHub Actions部署教程”，这个回滚思路一定得有。

顺手给你一个表格，帮你选路线：

纯 CI：适合先做测试、lint、build 校验，最快上手。
CI + SSH CD：适合自建服务器，成本低，控制力强。
CI + 容器镜像：适合微服务或多环境部署，规范性最好。

最后检查：怎么确认它真的好了

最后这一段很关键，别只看绿勾。你要自己验证三件事：第一，提交一个故意写错的测试，看看 workflow 是否真的失败；第二，改回正确代码后，确认 CI 自动恢复；第三，打一个 tag，检查 CD 是否按预期发布。我的验证方法很简单：看 Actions 页面里 job 是否全部 green，服务器上用 curl http://127.0.0.1:3000/health 或访问健康检查接口，确认返回 200。

如果你刚开始搭，建议先把“GitHub Actions CI/CD流水线配置教程”做成一个最小闭环：push 触发测试，tag 触发部署，失败能看到日志，成功能回查版本。这样你就不会被一堆花哨插件带偏。需要更多思路的话，官方文档和社区模板都能用；如果你想省时间，也可以把成熟方案作为参考，再回头按自己仓库改。最后，想看我继续拆 GitHub Actions 的缓存、矩阵构建、以及多环境发布，我就继续给你录下一期，记得留言告诉我你现在卡在哪一步。