小团队需要部署纪律，但通常不需要沉重流程。 目标是让发布足够可重复，不依赖记忆。好的流程应该保护生产环境，同时不让每个小改动都变得缓慢。 这是我偏好的 Web 产品和内部工具发布形态。

明确生产边界

改动任何东西之前，先明确这次发布真正拥有的范围。 它是前端容器？后端服务？单个 Nginx 路由？数据库迁移？还是一个 worker？ 很多生产事故来自触碰了不该触碰的范围。如果只是前端更新，就不应该重启后端或修改无关子域名。

流量变化前先构建

候选版本应该在生产流量参与前完成本地或 CI 构建。 这能提前发现依赖问题、类型错误、缺失资源和路由生成失败，而当前生产版本仍然保持不变。 对于 Next.js 服务，这通常意味着：

• 从 lockfile 安装依赖。
• 运行生产构建。
• 在本地或 canary 容器启动生产服务。
• 检查即将公开的真实页面。

并排部署新版本

尽可能把新版本启动在新的内部端口。 这样你会得到一个 canary 目标。可以在公开域名指向新服务之前检查 HTML、资源、健康接口、路由和日志。 这也让回滚更简单，因为旧路由仍然是已知的。

只切换目标路由

Nginx 改动应该尽量窄。 如果发布的是根站，就只改根站路由。不要触碰 API 子域名、聊天路由或无关反向代理。 最安全的发布，是爆炸半径最小的发布。

reload 前写好回滚

回滚脚本最好在切流之前就存在。 它应该恢复旧路由、测试 Nginx 配置，并在验证通过后 reload。脚本不需要复杂，但必须具体。 生产压力下，明确命令比美好意图可靠。

切换后验证

流量切走之后，检查公开 URL 和那些本不该变化的东西。 对于个人站点，这可能包括：

• 首页返回 200。
• About、Work、Blog、sitemap、robots 正常。
• 隐藏路由继续隐藏。
• 既有 upstream 路径保持原响应。
• 其它子域名仍然可访问。

小团队部署可以保持简单，但必须足够明确。