5

在我过去和现在的 Web 开发职位中，Staging / Beta 和 Production / Stable 环境共享一个数据库。

这是我对正在发生的事情的理解：

  • Staging / Beta 与 Production / Stable 的服务器基本相同，只是一般公众无法访问 Staging / Beta

  • 一旦 QA 的测试在其自己的生产/稳定数据的净化子集副本上通过即将进行的代码迭代，开发的下一步是确保即将进行的代码迭代将与完整的生产/稳定数据集一起使用，而不是打破现有的 Production / Stable 网站 - 这就是 Staging / Beta 的目的。此外，公司可以让 beta 测试人员使用全世界都可以看到的相同数据来测试代码。然后，当 beta 测试人员竖起大拇指时，它应该是从旧迭代到新代码迭代的简单切换。

我的一位直接下属称这是一种“气味”。他建议 Staging / Beta 应该拥有 Production / Stable 数据库的完整副本——因此，如果 Staging / Beta 代码确实存在问题，而在 QA 期间没有发现，它不会影响 Production / Stable 体验。这就是这两个链接的答案：

所以这是我的问题：在什么情况下，Staging / Beta 和 Production / Stable 应该共享一个数据库服务器？还是我现在和以前的公司做错了/便宜/等等？

预先感谢您的想法。

4

2 回答 2

3

仅当您没有足够的资源时才应共享资源:)

我不得不同意你的直接报告。您可能会遇到一些问题，而且它们并不少见：

  1. 测试过程从生产中窃取资源。
  2. 新代码被破坏并消耗太多资源（＃1的变化）
  3. 新代码需要一个不能与生产模式轻松并行的新模式。
  4. 在安装测试版更改的过程中，您会中断生产。

我真的不明白你怎么能原谅不单独托管分期/测试版。

于 2013-01-08T23:33:37.220 回答
3

目标似乎是：

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

我处于类似的环境中，我似乎无法找到允许上述情况的记录开发生命周期。我想说这是A/B 测试和“金丝雀发布策略”之间的交叉。

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

  1. alpha开发人员测试。这是开发人员推送分支和合并代码的地方。
  2. QA/分期用户测试。一旦新版本发布，这将与生产相同。）
  3. 为部分用户提供测试版。（我们正试图想出一个更好的名字，因为“测试版”的生产数据会让审计员感到紧张。我不确定“金丝雀”是否会飞……没有双关语的意思。
  4. www（通用生产）

Show stoppers 永远不应该进入 beta 版（在这种情况下），因为它是生产环境，与 staging/QA 是分开的。

如果您喜欢这个答案，也许您可​​以以我的名字命名发布周期或部署策略:)

于 2016-10-27T16:27:40.160 回答