Vercel、域名与 SSL 如何安全发布？自动化、灰度与回滚流程

为什么需要一套标准化的发布流程

很多开发团队使用 Vercel 的直觉是“push to deploy”——代码推送到 Git 仓库，Vercel 自动构建并部署到生产域名。这个模式对个人项目或原型验证足够了，但企业级项目涉及多环境管理、域名切换、SSL 证书续期、数据库迁移和用户流量控制，单靠默认的自动部署会带来几个现实问题。

第一个问题是域名和 SSL 的绑定时机。Vercel 在项目创建时会分配一个 *.vercel.app 的默认域名，这个域名自带自动续期的 SSL 证书。但生产环境通常需要绑定自定义域名，而自定义域名的 SSL 证书签发依赖 DNS 验证。如果 DNS 配置不当或证书签发延迟，发布过程中可能出现 HTTPS 中断。第二个问题是灰度能力。Vercel 原生提供 Preview Deployments 和 Production Deployments 的区分，但 Preview 环境默认使用随机子域名，无法直接模拟生产域名的流量分发。第三个问题是数据库变更。Vercel 本身不管理数据库，前端或全栈应用发布时，数据库 schema 变更的时机和顺序如果和代码发布脱节，很容易导致生产故障。

从项目交付角度看，发布流程的核心目标不是“快”，而是“可预测”。每一条发布的变更都应该被审计、可回滚，并且对用户的影响最小化。下面从构建、测试、发布、灰度、数据库变更和回滚六个环节展开具体做法。

构建环节：环境隔离与依赖锁定

构建阶段的安全保障从代码提交前就开始了。Vercel 的构建过程在云端执行，每个部署对应一个唯一的 Deployment ID。构建环境包括 Node.js 版本、系统依赖和缓存状态，这些因素在多次构建之间可能不一致，导致“本地能跑，线上失败”的情况。

锁定运行时版本

在项目根目录创建 .nvmrc 或 .node-version 文件，明确指定 Node.js 版本。Vercel 的构建环境默认使用最新的 LTS 版本，但企业项目通常需要固定版本以避免 API 兼容性问题。在 package.json 的 engines 字段中同样声明版本范围，并在 CI 脚本中校验。

环境变量分层管理

Vercel 的环境变量分为三个层级：Project-level、Environment-level（Production/Preview/Development）和 Branch-level。生产环境的 API 密钥、数据库连接串和第三方服务的 token 必须单独设置，不允许在代码仓库中存储。Preview 环境应该使用独立的测试数据库或 mock 服务，避免开发调试流量污染生产数据。

一个实用的做法是在 Vercel 控制台中为每个环境创建独立的 Environment Group，并开启“Encrypt”选项。对于敏感变量，还可以在 CI/CD 流水线中通过 Vercel CLI 注入，避免在 Web 界面中暴露。

依赖缓存与完整性校验

Vercel 默认缓存 node_modules 和 .next/cache（对于 Next.js 项目），但缓存命中失败会导致构建时间增加。更关键的是，依赖包的版本锁定必须使用 lock 文件（package-lock.json 或 yarn.lock）。在构建脚本中增加 `npm ci` 而不是 `npm install`，前者会严格依据 lock 文件安装，拒绝任何版本偏差。

如果项目使用了私有 npm 包或 monorepo 结构，需要在 vercel.json 中配置 `buildCommand` 和 `installCommand`，并确保所有依赖都能在构建环境中解析。Monorepo 场景下，Vercel 的 TurboRepo 集成可以只构建变更过的包，但需要提前在根目录配置好 pipeline。

测试环节：在 Preview 部署中嵌入自动化验证

Vercel 的 Preview Deployments 为每个 Pull Request 生成一个独立 URL，这个 URL 可以用来运行集成测试和视觉回归测试。但 Preview 环境默认使用 *.vercel.app 域名，如果应用依赖自定义域名的 cookie 或 CORS 策略，测试结果可能不准确。

为 Preview 环境绑定临时子域名

当项目需要测试 OAuth 登录、第三方回调或自定义域名下的跨域行为时，Preview 的随机域名无法满足要求。解决方案是在 DNS 提供商处配置通配符子域名（如 *.preview.yourdomain.com），然后在 Vercel 的 Domain 设置中为 Preview 环境添加该通配符域名。这样每个 Preview 部署会获得一个类似 `pr-123.preview.yourdomain.com` 的 URL，证书由 Vercel 自动签发。

需要注意的是，通配符证书的 DNS 验证需要配置 TXT 记录，Vercel 会在添加域名时给出具体的记录值。这个配置是一次性的，后续每个 Preview 部署都会自动继承。

CI 集成测试

在 GitHub Actions 或 GitLab CI 中，可以在构建完成后获取 Preview URL，然后运行 Playwright 或 Cypress 测试。Vercel 提供了 `vercel list` 和 `vercel inspect` 命令来获取部署状态和 URL，但更推荐使用 Vercel 的 Deploy Hooks 或 GitHub Checks API 来同步状态。

关键点是测试失败时阻止合并。在 PR 的 CI 流程中，如果集成测试未通过，Vercel 的 Status Checks 应该标记为失败，阻止代码合入主分支。这个逻辑需要在仓库的 Branch Protection Rules 中配置。

性能与安全扫描

在每个 Preview 部署上运行 Lighthouse 性能审计和安全头部检查（如 Content-Security-Policy、X-Frame-Options）。Vercel 的 Edge Network 会自动添加一些安全头部，但应用层面的策略需要开发者自行配置。可以在 next.config.js 或 vercel.json 中设置 `headers` 字段，确保每个环境都有一致的安全策略。

发布环节：从 Preview 到 Production 的切换策略

Vercel 的 Production 部署默认绑定主分支（通常是 main 或 master）。当代码合并到主分支时，Vercel 自动触发构建并部署到生产域名。这个流程对于小型团队没问题，但企业项目需要更精细的控制。

使用 Vercel CLI 手动触发生产部署

在 CI 中，不要依赖自动部署，而是显式调用 `vercel --prod` 命令。这样做的好处是可以控制部署时机——例如在合并 PR 后先运行一轮更全面的回归测试，再执行生产部署。Vercel CLI 需要配置 token，在 CI 环境中通过环境变量 `VERCEL_TOKEN` 传入。

部署命令示例：
```
vercel --prod --token=$VERCEL_TOKEN --scope=my-team
```
如果项目使用 monorepo，需要指定 `--cwd` 参数。

域名切换的原子性

Vercel 支持为同一个项目绑定多个域名，并且可以设置一个域名为主域名。当新部署就绪时，Vercel 的 Edge Network 会在几秒内将流量切换到新版本，这个过程是原子的——不会出现部分用户看到旧版本、部分用户看到新版本的情况。但前提是 DNS 解析已经稳定指向 Vercel 的 Edge Network。

如果从其他平台迁移到 Vercel，域名切换的步骤是：
1. 在 Vercel 项目中添加自定义域名，完成 DNS 验证。
2. 将 DNS 的 CNAME 记录指向 `cname.vercel-dns.com`。
3. 等待 DNS 传播（通常几分钟到一小时）。
4. 在旧平台停止服务或修改 DNS TTL 到最小值。

对于已经绑定域名的项目，域名切换本身不涉及停机，因为 Vercel 的 SSL 证书签发是异步的。但需要注意，证书签发失败时，Vercel 会回退到 *.vercel.app 域名，导致用户访问自定义域名时出现证书错误。所以每次添加或修改域名后，应该检查 Vercel 控制台中的 SSL 状态，确认“Certificate Status”为“OK”。

灰度发布：利用 Vercel 的 Edge Config 和 Feature Flags

Vercel 原生没有提供类似 Kubernetes 的流量比例灰度功能，但可以通过 Feature Flags 结合 Edge Config 实现灰度发布。核心思路是：所有用户访问同一个生产 URL，但根据用户标识（如用户 ID、IP 或 Cookie）返回不同版本的内容。

基于 Edge Config 的 Feature Flags

Vercel 的 Edge Config 是一个全局 KV 存储，可以在 Edge Functions 中低延迟读取。在 Edge Config 中存储一个 JSON 对象，定义各个 Feature Flag 的开启状态和灰度比例。例如：
```json
{
"new-checkout": {
"enabled": true,
"percentage": 10,
"whitelist": ["user_id_123", "user_id_456"]
}
}
```
然后在 Edge Middleware 中读取请求的 Cookie 或 Header，判断当前用户是否属于灰度范围。如果是，则返回新版本的页面或 API 响应；否则返回旧版本。

灰度发布的操作流程

1. 将新版本的代码部署到 Production 环境（Vercel 会自动分配一个 Deployment URL）。
2. 在 Edge Config 中设置 Feature Flag，灰度比例从 0% 开始。
3. 逐步增加比例（1% → 5% → 10% → 50% → 100%），每次调整后观察监控指标（错误率、响应时间、业务转化率）。
4. 如果发现问题，立即将比例回退到 0%，或者从 whitelist 中移除异常用户。
5. 当灰度比例达到 100% 且稳定运行一段时间后，移除 Feature Flag 代码，发布一个清理版本。

这个方案的代价是代码中需要维护 Feature Flag 的分支逻辑，增加了代码复杂度。对于简单的 UI 变更，也可以考虑使用 Vercel 的 A/B Testing 功能（基于 Edge Functions 的 Split Testing），但需要提前在 vercel.json 中配置实验规则。

数据库变更：与代码发布协调的时机

这是最容易出问题的环节。Vercel 部署的应用如果连接数据库（如 PostgreSQL、MongoDB 或 Prisma），数据库 schema 的变更必须与代码发布严格对齐。常见的故障场景是：新代码依赖新增的数据库字段，但数据库迁移尚未执行，导致查询报错；或者数据库迁移删除了旧字段，但旧代码仍在运行，导致写入失败。

向前兼容的迁移策略

基本原则是：数据库 schema 的每一次变更都必须向前兼容，即旧代码仍然能正常工作。具体做法是分多步发布：

• 第一步：新增字段或表，但不修改旧代码。部署迁移脚本，让新字段允许 NULL 或设置默认值。
• 第二步：部署新代码，开始读写新字段。旧代码忽略新字段，不会报错。
• 第三步：在旧代码不再运行后，清理不再使用的字段或表。

这个策略在 Vercel 的部署模型下尤其重要，因为 Vercel 的 Production 部署是立即全局生效的，没有金丝雀发布的流量控制。如果数据库迁移失败，回滚代码比回滚数据库更容易。

在 CI 中执行数据库迁移

在 CI 的生产部署步骤中，数据库迁移应该作为独立阶段执行。顺序是：
1. 运行数据库迁移脚本（如 `prisma migrate deploy` 或 `knex migrate:latest`）。
2. 等待迁移完成，验证 schema 状态。
3. 触发 Vercel 生产部署。

如果迁移失败，必须中断部署流程，并通知团队手动修复。Vercel 的 Deploy Hooks 可以设置为在迁移成功后才触发构建，但更可靠的方式是在 CI 脚本中显式控制顺序。

回滚数据库变更

数据库回滚比代码回滚复杂。如果迁移脚本是向下兼容的（只新增不删除），回滚代码后数据库无需回滚。如果迁移包含了破坏性变更（如重命名列），则需要在迁移脚本中编写 `down` 方法，并确保回滚时数据不丢失。

一个实用建议是：在生产环境中永远不要执行破坏性迁移。所有 schema 变更都应该是 additive 的。这样代码回滚后，数据库仍然处于可用状态。

回滚流程：自动回滚与手动干预的边界

Vercel 提供 Instant Rollback 功能，可以在控制台中一键回滚到之前的任何一个 Production 部署。回滚后，域名和 SSL 证书保持不变，流量立即切换到旧版本。这个功能在紧急故障时非常有用，但需要提前做好几件事。

保留足够的部署历史

Vercel 默认保留最近的 10 个 Production 部署，但可以调整保留策略。在项目设置中开启“Retain all deployments”选项，或者设置保留数量为 50 以上。同时，每个部署应该关联对应的 Git Commit，方便追溯回滚的代码版本。

回滚前确认数据库兼容性

回滚代码之前，必须确认当前数据库 schema 与旧代码兼容。如果数据库已经执行了向前兼容的迁移（只新增字段），回滚代码通常没有问题。但如果数据库执行了不可逆的变更（如删除表），回滚代码可能导致旧代码尝试访问不存在的表。

一个安全做法是：在回滚代码之前，先检查最后一次成功部署时的数据库 schema 状态。如果无法确认，优先选择回滚数据库迁移再回滚代码，或者直接使用数据库备份恢复。

自动回滚条件

在 CI 中配置自动回滚的触发条件：

• 部署后的 5 分钟内，错误率超过阈值（如 5%）。
• 关键 API 的响应时间超过基线值的 3 倍。
• 监控系统检测到 500 错误激增。

自动回滚需要谨慎启用，因为误判可能导致频繁回滚。建议先设置为手动确认模式：CI 检测到异常后，在团队通讯工具中发送告警，由值班人员决定是否执行回滚。SystemDo 在多个企业项目中采用这种半自动模式，既保证了响应速度，又避免了自动化误操作。

监控与审计：发布后的持续验证

发布完成不等于流程结束。Vercel 提供 Deployment Logs 和 Analytics，但企业项目需要更全面的监控覆盖。

日志与错误追踪

将 Vercel 的日志导出到外部日志平台（如 Datadog、Sentry 或 Grafana）。Vercel 支持通过 Log Drains 将日志实时推送到自定义 HTTP 端点。配置 Log Drains 后，每个部署的请求日志、函数调用日志和构建日志都可以集中分析。

自定义域名证书到期提醒

Vercel 会自动续期 SSL 证书，但续期依赖 DNS 验证。如果 DNS 配置被误修改或域名过期，证书续期会失败。建议在 DNS 提供商处设置 TTL 监控，并在 Vercel 的 Domain 设置中定期检查“Renewal Status”。对于关键域名，可以在外部监控服务中配置 SSL 证书到期告警，提前 30 天通知。

发布审计日志

每次生产部署都应该在团队内部记录：部署时间、变更内容、部署人、关联的 Issue 或 Ticket。Vercel 的 API 可以获取部署历史，但审计日志最好与项目管理工具（如 Linear、Jira）集成，形成可追溯的发布记录。

总结

Vercel 的部署能力在个人项目和原型阶段非常便捷，但进入企业交付场景后，安全发布的重点就转移到了流程控制上。域名绑定和 SSL 证书管理需要提前规划 DNS 记录和验证策略；灰度发布依赖 Feature Flags 和 Edge Config 的组合实现；数据库变更必须遵循向前兼容的原则；回滚流程需要在代码和数据库两个层面都做好预案。

这套流程不是一次性搭建的，而是随着项目复杂度逐步完善的。初期可以先实现自动构建和 Preview 测试，然后加入手动生产部署和数据库迁移协调，最后再引入灰度发布和自动回滚。每一步的投入都应该基于实际的风险评估——一个日活百万的应用和一个内部管理系统的发布流程自然不同。