GitHub Actions 部署

把这个人加入 Vercel，让其能够部署。或者干脆别加。

一个历史 GitHub Actions 工作流如何处理共享预发布环境和授权生产发布，而无需为每名工程师购买 Vercel 席位。

2026年5月26日阅读时间：5分钟作者 Abdullah Raheel

所有文章

控制台访问权不等于部署权

实现这套方案时，Vercel Pro 每个席位收费 $20。三名工程师每月需要 $60，五到六名则需要 $100～$120。团队保留一个 $20 的项目席位，并通过 Vercel CLI 把部署执行迁入 GitHub Actions。

代码仓库把 VERCEL_TOKEN、VERCEL_ORG_ID 和 VERCEL_PROJECT_ID 保存为密钥。工程师可以通过常规的基于主干开发的合并路径交付经过评审的工作，而无需每人获得控制台凭据。

分离预发布环境与生产环境

我把部署拆成两个工作流。合并到 main 会更新预发布环境；生产发布则必须由经过授权的 GitHub 操作者在 QA 后手动触发。

拉取请求 -> 评审 -> 合并到 main
  -> 自动构建并部署预发布环境
  -> QA
  -> 授权生产工作流
  -> 标签、发布、部署、Slack 通知

拥有代码仓库访问权限并不自动获得生产权限。原工作流允许 Elusive7733 触发生产发布，其余团队成员则通过拉取请求和预发布环境交付更改。

自动部署评审环境

每次推送到 main 都会拉取预发布环境，使用 --target=staging 构建预构建产物，再部署这份确切输出。共享并发组使用 cancel-in-progress: true，使较新的 main 提交取代已经过时且仍在排队或运行的预发布部署。

concurrency:
  group: staging-deploy
  cancel-in-progress: true

- run: vercel pull --yes --environment=staging --token=$VERCEL_TOKEN
- run: vercel build --target=staging --token=$VERCEL_TOKEN
- run: vercel deploy --prebuilt --target=staging --token=$VERCEL_TOKEN

生产发布必须明确触发

手动生产工作流接受 patch、minor 或 major。获取完整 Git 历史后，它读取最新标签、计算下一个语义化版本、创建并推送标签、拉取生产环境、构建预构建产物，再完成部署。

单独的 skip-tagging 路径会复用最新版本进行重新部署。恢复发布时，无需仅为了重新运行基础设施而创建虚假的新版本号。

on:
  workflow_dispatch:
    inputs:
      version_type:
        type: choice
        options: [patch, minor, major]
      skip_tagging:
        type: boolean
        default: false

留下可追溯的运维记录

完成带标签的发布后，gh release create --generate-notes 会生成变更日志。.github/release.yml 按标签对拉取请求分组。工作流追加部署元数据，并通过 Slack webhook 发送格式化的发布信息。

我先构建了一个 AI 变更日志生成器，三天后便将其删除。GitHub 已列出每个已合并的拉取请求及其链接，因此模型只增加代码，没有增加有用的发布信息。

只为系统真正需要的权限付费

实际工作顺序很简单：合并经过评审的拉取请求，部署到预发布环境，完成验证，再由授权操作者触发生产发布。版本标签、GitHub 发布和 Slack 消息会在 Vercel 控制台之外留下发布记录。

对取代控制台访问权限的凭据使用代码仓库和环境保护。
把用于评审的自动部署与主动触发的生产执行分开。
每个环境只构建一次，并部署预构建产物。
先把原生发布说明作为默认方案，再考虑增加另一套生成系统。