在我过去和现在的web开发职位中，登台/Beta和生产/稳定环境共享一个数据库。
这是我对发生的事情的理解:
-
暂版/Beta版基本上与生产版/稳定版的服务器相同，只是公众无法访问暂版/Beta版
-
一旦QA的测试通过了即将到来的生产/稳定数据子集副本上的代码迭代，开发的下一步是确保即将到来的代码迭代将与全套生产/稳定数据一起工作，同时不会破坏现有的生产/稳定网站——这就是登台/测试版的目的。此外，公司可以让beta测试人员使用全世界都能看到的相同数据来测试代码。然后，当测试人员竖起大拇指时，应该是一个从旧迭代到新迭代的简单切换。
我的一个直接下属称这种现象为"气味"。他建议，测试阶段/测试版应该有一个生产/稳定版数据库的完整副本——这样，如果测试阶段/测试版代码真的有问题，但在QA期间没有被发现，它不会影响生产/稳定版的体验。这就是通过这两个链接得到的答案:
- 暂存环境设置
- 暂存数据库困境
提前感谢您的关心。
目标似乎是:
- 允许一部分用户使用新版本(非常适合敏捷工作流程)
- 避免数据丢失或唯一密钥丢失/重复，因为两个版本同时运行
我在一个类似的环境中，我似乎找不到一个允许上述情况的文档化开发生命周期。我认为这是 a/B测试和"金丝雀发布策略"之间的交叉。
我们用第四个环境解决了这个问题，介于测试和生产之间(我们称之为beta，尽管它实际上是生产):
- alpha开发者测试。这是开发者推送分支和合并代码的地方。
- QA/staging用户测试。一旦新版本发布，这将与生产相同。)
- beta版产品供部分用户使用。(我们正试图想出一个更好的名字，因为生产数据的"beta"会让审计人员感到紧张……我不确定"金丝雀"是否会飞起来……没有双关语。
- www(一般可用产品)
Show stoppers不应该进入beta(在这种情况下)，因为它是产品，与登台/QA分开。
如果你喜欢这个答案，也许你可以用我的名字来命名发布周期或部署策略:)
只有当你没有足够的资源时才应该共享资源:)
我不得不同意你的直接报告。您可能会遇到一些问题，它们并不少见:- 测试过程窃取生产资源。
- 新代码被破坏并且消耗了太多的资源(#1的变化)
- 新代码需要一个新的模式，它不能轻易地与生产模式共存。
- 在安装测试版更改的过程中，您会中断生产。
我真的不明白你怎么能原谅不单独托管阶段/测试版。