【发布时间】：2018-10-21 16:27:42
【问题描述】：
您能否向我们推荐使用 nextjs 在生产环境中部署应用程序的最佳实践？
我们正在考虑以下策略：金丝雀部署、蓝/绿部署...我们有几个疑问要处理 BUILD_ID。
现在，通过这种策略，我们正面临这个错误：
INVALID_BUILD_ID，因为在部署的某个时刻，我们在 应用程序的至少两个不同版本。
例如：
在 Canary 部署中，我们有两个不同的版本，平衡器将客户端发送到 版本 A，但是当客户端需要其他资源时，平衡器可以将此请求发送到 版本为 B 的服务器。此时，当应用获取 serp.js、_error.js、_document.js 等资源且网页未正确加载时，客户端会收到 500 错误。
_next/f6bff019-9550-4029-99fa-2b33a50045f6/page/index.js ---> old (previous deployment)
_next/005b2202-c5b2-4de6-afd8-1c8451d16ab3/page/index.js ---> new (current deployment)
到目前为止，我们已经测试过：
重命名 BUILD_ID 以在两个版本中具有相同的哈希值，但我们认为这是一种不好的做法，因为我们认为客户端的缓存不会按预期刷新。
Sticky session 是最可靠的，但我们将无状态应用程序作为有状态的应用程序来处理，事实并非如此。
我们可以在前面放置一个缓存 BUILD_ID 的 CDN，但我们不确定应该为 js 文件的缓存分配的时间。
【问题讨论】：
-
这似乎是一个真正的问题.. 我只是好奇。即使 NextJS 不在图片中，将应用程序的新旧版本放在相同的负载平衡后也会出于相同的原因导致问题，对吧？也许将它们部署为单独的应用程序并使用另一层进行基于会话的 A/B 测试可能会缓解这个问题
-
如果您的部署每次都以相同的顺序（服务器 A > B > C）发生，请参见：serverfault.com/questions/537269/…。我们有两个配置，部署后备/生产负载平衡，我们符号链接到 nginx 配置。
-
@alberto，你有什么解决办法？
标签： javascript node.js deployment next.js isomorphic-javascript