在哪些情况下，暂存/测试和生产/稳定环境应共享一个数据库？

Question

在我之前和现在的网络开发职位中，Staging / Beta 和 Production / Stable 环境共享一个数据库。

以下是我的理解：

- Staging / Beta 基本上与 Production / Stable 的服务器相同，只是公众无法访问 Staging / Beta。 - 一旦 QA 在自己的经过消毒的 Production / Stable 数据子集上通过了即将推出的代码迭代的测试，开发的下一步就是确保即将推出的代码迭代能够使用完整的 Production / Stable 数据集而不会破坏现有的 Production / Stable 网站 - 这就是 Staging / Beta 的目的。此外，公司可以让测试人员使用与全世界看到的相同的数据来测试代码。然后，当测试人员给出肯定答复时，从旧的代码迭代切换到新的代码迭代应该是一个简单的过程。 - 我的一位直接下属称这是一种“气味”。他建议 Staging / Beta 应该拥有 Production / Stable 数据库的完整副本 - 因此，如果在 QA 过程中没有发现的问题确实存在于 Staging / Beta 代码中，它也不会影响 Production / Stable 的使用体验。这是这两个链接的答案：

• 设置演示环境
• 演示数据库问题

那么我的问题是：在什么情况下，演示 / 测试环境和生产 / 稳定环境应该共用一个数据库服务器？还是我目前的公司和之前的公司做事方式不对 / 太过节省成本等等？

提前感谢您的回答。

- theschles

Answer 1

目标似乎是：

1. 允许一部分用户使用新版本（非常适用于敏捷工作流程）
2. 避免数据丢失或唯一键丢失/重复，因为两个版本同时运行

我在类似的环境中，但似乎找不到一个文档化的开发生命周期来实现上述目标。我认为这是A/B测试和“金丝雀发布策略”之间的结合。

我们通过第四个环境来解决这个问题，在测试和生产之间（尽管它实际上是生产），我们称之为beta：

1. alpha 开发者测试。这是开发人员推送分支和合并代码的地方。
2. QA/staging 用户测试。这将与新版本发布后的生产环境完全相同。
3. beta 生产环境的一部分用户。（我们正在努力想出更好的名称，因为在“beta”上具有生产数据会让审计员感到紧张...我不确定“金丝雀”是否可行...没有双关语。）
4. www（普遍可用的生产环境）

在这种情况下，展示阻碍应该永远不会进入beta测试，因为它是与分离的生产环境和暂存/质量保证环境不同的。如果你喜欢这个答案，也许你可以以我的名字命名发布周期或部署策略 :)

- Frank Forte

Answer 2

只有在没有足够的资源时才应共享资源 :)

我必须同意您的直接报告。您可能会遇到一些问题，这些问题并不太罕见：

1. 测试过程从生产中夺取了资源。
2. 新代码出现故障并消耗了过多的资源（变化#1）。
3. 新代码需要一个新模式，该模式不能轻松地与生产模式并存。
4. 在为beta安装更改的过程中，您破坏了生产环境。

我真的看不出您如何不需要单独托管分段/测试版。

- Cargo23

---

如果我们正在构建类似于WhatsApp的应用程序，那怎么办？在WhatsApp中，测试用户和生产用户可以在同一群组中，他们是否共享一个生产和测试版本的应用程序单一数据库？我之所以这样问是因为我们正在构建一种类似的Android应用程序，其中包含“用户组”。 - Mathew John

@MathewJohn，你在这里的困惑涉及到客户端和服务器之间的区别。Beta版WhatsApp用户正在使用连接到与生产版WhatsApp用户相同的生产版WhatsApp服务的Beta客户端。 - Cargo23