团队在选部署策略,蓝绿 vs 滚动 vs 金丝雀,每种都说自己好。说说我的理解。
- 蓝绿:两套环境,切流量瞬间完成,回滚秒级。资源占用翻倍。
- 滚动:渐进替换,资源省,但回滚慢,滚动期间混合版本。
- 金丝雀:先放一小撮流量观察,最稳,但配置最复杂。
我们的选择:
- 数据库 migration 涉及的发布 → 蓝绿(保证可回滚)。
- 普通迭代 → 滚动。
- 大版本 / 高风险 → 金丝雀。
没有银弹,按场景选。
大家都用什么部署策略?
团队在选部署策略,蓝绿 vs 滚动 vs 金丝雀,每种都说自己好。说说我的理解。
我们的选择:
没有银弹,按场景选。
大家都用什么部署策略?
暂时没有回复。
Related
讨论
几台机器上跑了好几个 Next.js 应用,每个都自带一份 node modules,磁盘和构建时间都顶不住。想试试 shared node modules,但又怕依赖版本冲突。 查了下, output: 'standalone' 模式只会打包运行时真正用到的依赖,体积小很多,但
讨论
用 output: 'standalone' 出来的 .next/standalone 目录,理论上拷到服务器直接 node server.js 就能跑。但实际部署我踩了好几个坑。 public/ 和 .next/static 不会被打进 standalone,得手动拷。 路径都
讨论
Next.js 里每条路由都能选 runtime,Edge 快、便宜、全球分布,但 API 受限;Node 慢但全功能。怎么选一直纠结。 我的判断: middleware、纯转发、轻量计算 → Edge。 重业务、用到 Node 库(Prisma、Sharp、pdf)→ Node
讨论
几个内部包 + 主应用 + 文档站,迁到 pnpm workspace,整体体验不错。比 npm/yarn workspace 稳很多。 关键配置: 用 workspace: 协议锁内部包版本。 filter 做按需构建,CI 时间砍半。 用 changesets 管版本发布。