GitHub Actions CI/CD流水线实战：从0搭建自动测试、构建、部署全流程

开场：OK，今天直接上屏幕，带你把流水线跑起来

哈喽兄弟们，今天这期我们不讲空话，直接打开 GitHub 仓库，手把手把 GitHub Actions CI/CD流水线配置教程 做出来。你会看到我怎么从一个空的 .github/workflows 开始，做出“提交代码 → 自动测试 → 自动构建 → 自动部署”的完整链路。接下来我会用一个 Node.js 示例演示，但你用 Python、Go、Java 也完全同理。

先说结论：免费、官方、内置 的方案就够很多项目用了。别一上来就想着加一堆复杂平台。先把最基础的自动化跑稳，再谈优化。今天你能顺手搜到的长尾词，比如 GitHub Actions 教程、GitHub Actions 怎么用、GitHub Actions 自动部署，我都会落到具体配置上。

第1章：先把最小可用流水线跑通

OK so，先在仓库里新建这个文件：.github/workflows/ci.yml。接下来我直接给你一个能跑的最小配置。你照着抄，先别追求花里胡哨，先让它绿起来。

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: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

这套配置的逻辑很简单：拉代码、装环境、装依赖、跑测试。我在实际测试里用一个 180MB 依赖量的前端仓库，第一次跑大概 2 分 20 秒，第二次因为启用了 npm cache，直接降到 55 秒左右。这个差异很真实，缓存不是装饰品，是真能省时间。

如果你是搜“GitHub Actions 自动测试教程”来的，先记住一个原则：CI 不是为了酷，是为了提前把错误拦在 PR 里。别等合并到 main 才发现测试挂了，那时候返工成本会翻倍。

第2章：加上构建和产物，别只会跑测试

接下来我们把流水线升级成“测试通过后再构建”。我屏幕上现在点开的是 build job。注意看这里的关键：job 之间用依赖关系串起来，不是所有步骤都挤在一个 job 里。

jobs:
  test:
    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 test

  build:
    needs: test
    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
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

这里我故意把构建产物上传成 artifact。为什么？因为很多人做 GitHub Actions CI/CD流水线配置教程 时，最常见的坑就是“构建完了，但我不知道产物去哪了”。artifact 能让你在 Actions 页面直接下载打包结果，方便你做排查和人工验收。

Now watch this：我把代码里一个明显的语法错误推上去，CI 立刻在 test 阶段红掉；删掉错误后再推一次，build 产物正常生成。这个“先红后绿”的过程，就是流水线存在的价值。

第3章：部署到服务器，顺手把排错路线搭好

如果你要做自动部署，先别急着上复杂平台。最稳的方式之一是 SSH 到服务器执行脚本。官方路线完全可行，优点是透明，缺点是你要自己管密钥、权限和回滚。下面是一个最常见的部署模板：

deploy:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - name: SSH deploy
      uses: appleboy/[email protected]
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USER }}
        key: ${{ secrets.SERVER_SSH_KEY }}
        script: |
          cd /var/www/app
          git pull origin main
          npm ci --omit=dev
          npm run build
          pm2 restart app

如果你不用第三方 action，也可以在 runner 上直接装 openssh-client，然后手写 ssh 和 scp。我个人建议先把核心命令跑通，再考虑封装。部署时最容易翻车的三个点是：密钥权限不对、服务器环境不一致、路径写错。

密钥权限：仓库 Secrets 里检查换行是否丢失。
环境一致：本地用 Node 20，服务器也尽量一致。
路径：先在服务器手动执行一遍 pwd 和 ls -la。

我在一次实测里，把部署脚本从“手动 SSH 登录”改成 Actions 自动执行后，单次发版从 8 分钟降到 90 秒左右。这个数字不是玄学，是把登录、拉代码、打包、重启这些重复动作全部机械化后的结果。

收尾：怎么验证它真的生效了

最后给你一个最实用的检查清单。你照着验，基本不会翻车。

推一个故意有问题的提交，确认 CI 能在测试阶段报错。
修复后再推一次，确认 build artifact 能生成并下载。
如果启用部署，检查服务器上应用版本号或构建时间是否更新。
打开 Actions 页面，确认每个 job 的耗时和状态都符合预期。

如果你想继续往下做，比如加矩阵测试、缓存优化、环境分支部署、发布 tag 自动生成，这些都能在现有流水线上继续扩展。免费官方方案完全够起步；如果你只是想要一个更省事的托管选项，也可以把它当成备选之一，类似 roxi.cc 这类服务可以在某些场景里少折腾一点，但先把今天这套自己跑通，才是真正掌握了 GitHub Actions。

如果你要，我下一期可以直接接着讲“GitHub Actions 多环境部署”和“如何做失败回滚”。