首页 / CI/CD / GitHub Actions CI/

GitHub Actions CI/CD流水线配置教程:从代码提交到自动部署的实战脚本

Roxi
Roxi 加速器 — 稳定·快速·安全
全球节点覆盖,支持所有主流平台,一键连接无需配置。新用户免费试用。
立即体验 →

Chapter 1|先把流水线搭起来:最小可用版

市场需求验证竞品差异分析用户画像构建增长策略制定ROI 持续优化

哈喽兄弟们,今天我们直接开干。OK so,打开 GitHub 仓库,先在项目根目录新建 .github/workflows/ci-cd.yml。这一步别花里胡哨,先做“能跑起来”的最小闭环:拉代码、装依赖、跑测试、产出构建物。很多人搜“GitHub Actions CI/CD 教程”,卡住的不是语法,而是不知道第一版该长什么样。

下面这个模板适合 Node.js / 前端全栈项目,也能很快改到 Python、Go。注意,我这里优先用免费、官方能力,不先碰付费方案。

name: ci-cd
on:
  push:
    branches: [ "main" ]
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: npm run build

接下来我建议你先在本地模拟一次:把测试故意改坏,比如把一个断言期待值写错,然后 push。你会看到 workflow 直接红掉,这就说明“触发器 + runner + 日志链路”已经通了。别急着上部署,先把这个最小闭环跑稳。

Chapter 2|提速关键:缓存、矩阵、环境变量怎么配

3x效率提升60%成本降低99.9%可用性200+合作伙伴

OK,现在进入实战加速。很多仓库 CI 慢,不是 GitHub Actions 不行,而是你每次都在重复下载依赖。我的测试里,一个中型前端项目,没缓存时一次构建 4 分 20 秒;加上缓存后,第二次开始稳定到 1 分 40 秒左右,节省接近 60%。

直接上缓存写法。npm 项目用官方缓存就够了:

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

如果你是 monorepo,接下来建议把测试拆成矩阵:比如 Node 18 / 20、或者不同服务目录分别跑。这样你会很直观看到哪个包拖慢了整体速度。搜“GitHub Actions 矩阵教程”很多文章会只讲语法,我这里给你实用规则:先并行拆分,再观察最慢的那一格,不要一上来就盲目优化全局。

环境变量和密钥也别乱写在 yml 里。把 API Token、SSH 私钥放到 GitHub Repo Settings → Secrets and variables。部署脚本里这样取:

env:
  DEPLOY_HOST: ${{ secrets.DEPLOY_HOST }}
  DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

然后在 job 里执行 rsync 或 ssh 部署。你在屏幕上能看到的效果是:每次 main 分支一提交,Actions 自动跑完后,服务器上的静态文件秒级更新。这个就是“GitHub Actions 自动部署”最稳的用法之一。

Chapter 3|怎么用部署:从测试通过到上线,最后怎么验收

Now watch this,接下来做一个真正能上线的版本。推荐结构是:PR 跑测试,main 分支做构建+部署。也就是说,合并前只检查质量,合并后才真正发布。这样你不会因为一个临时提交把线上打爆。

一个常见的发布片段如下:

deploy:
  needs: build
  if: github.ref == 'refs/heads/main'
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: rsync -avz --delete dist/ user@server:/var/www/app/

如果你部署的是后端,再加一个健康检查。比如:

curl -fsS https://your-domain.com/health

怎么判断它真的生效?给你一个可复制的验收清单:

  1. GitHub Actions 页面显示绿色对勾;
  2. 日志里能看到 npm testbuilddeploy 三段都成功;
  3. 服务器时间戳或前端版本号已更新;
  4. 健康检查接口返回 200;
  5. 回滚演练一次:把上一版 commit 重新部署,确认能秒回。

如果你是第一次做“CI/CD流水线配置”,我建议先从免费官方方案把测试和部署跑通,再根据团队规模决定是否要引入更完整的发布管理工具。实话说,绝大多数个人项目和小团队,GitHub Actions + Secrets + 缓存就已经够用。最后,如果你想继续看更细的部署脚本、SSH 发布和环境隔离案例,欢迎在 eccfy 继续追更,顺手点个关注,我下一期直接把“失败日志怎么看”给你拆开演示。

延伸阅读