GitHub Actions 自动部署实战：从检查到发布的完整流程

GitHub Actions 不只适合跑检查，也适合做自动部署。关键是把流程拆清楚：先检查，再构建，最后部署。任何一步失败，都不要继续往下走。

基础可以先看 GitHub Actions 入门：为博客加自动检查。

一个基本流程

1
name: Deploy
2

3
on:
4
  push:
5
    branches: [main]
6

7
jobs:
8
  deploy:
9
    runs-on: ubuntu-latest
10
    steps:
11
      - uses: actions/checkout@v4
12

13
      - uses: actions/setup-node@v4
14
        with:
15
          node-version: 22
16

17
      - run: npm ci
18
      - run: npm run verify
19
      - run: npm run deploy
20
        env:
21
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

这里最重要的是 npm run verify 在部署前执行。检查不过就不要发布。

密钥放在哪里

部署 token 不要写进仓库。放到 GitHub 仓库的 Secrets 里，然后通过环境变量传给部署命令。

命名尽量清楚：

1
CLOUDFLARE_API_TOKEN
2
DEPLOY_SSH_KEY
3
SERVER_HOST
4
SERVER_USER

权限也要收窄。能只部署一个项目，就不要给账号全部权限。

SSH 部署的写法

如果是部署到服务器，可以用 SSH：

1
- name: Setup SSH
2
  run: |
3
    mkdir -p ~/.ssh
4
    echo "${{ secrets.DEPLOY_SSH_KEY }}" > ~/.ssh/id_ed25519
5
    chmod 600 ~/.ssh/id_ed25519
6

7
- name: Deploy
8
  run: |
9
    ssh -o StrictHostKeyChecking=accept-new deploy@server 'cd /srv/app && ./deploy.sh'

服务器上的 deploy.sh 要尽量可重复执行，不要依赖手工步骤。

失败时怎么办

自动部署不是只管成功路径。至少要考虑：

• 构建失败不部署
• 部署失败能看到日志
• 上一个版本能恢复
• 数据库迁移失败不会继续启动新代码

对于 Docker 项目，可以保留上一个镜像 tag。对于静态站点，通常重新部署上一版即可。

不要把所有事都塞进 workflow

workflow 负责调度，复杂逻辑放脚本里。这样本地也能执行同样流程。

1
set -e
2
git pull
3
docker compose build
4
docker compose up -d
5
docker compose ps

总结

自动部署的目标不是炫技，而是减少漏步骤。流程越接近日常手动发布，越容易维护。先把检查、构建、部署拆清楚，再逐步加通知、回滚和环境保护。