在我之前和现在的网络开发职位中,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 的使用体验。这是这两个链接的答案:
以下是我的理解:
- Staging / Beta 基本上与 Production / Stable 的服务器相同,只是公众无法访问 Staging / Beta。 - 一旦 QA 在自己的经过消毒的 Production / Stable 数据子集上通过了即将推出的代码迭代的测试,开发的下一步就是确保即将推出的代码迭代能够使用完整的 Production / Stable 数据集而不会破坏现有的 Production / Stable 网站 - 这就是 Staging / Beta 的目的。此外,公司可以让测试人员使用与全世界看到的相同的数据来测试代码。然后,当测试人员给出肯定答复时,从旧的代码迭代切换到新的代码迭代应该是一个简单的过程。 - 我的一位直接下属称这是一种“气味”。他建议 Staging / Beta 应该拥有 Production / Stable 数据库的完整副本 - 因此,如果在 QA 过程中没有发现的问题确实存在于 Staging / Beta 代码中,它也不会影响 Production / Stable 的使用体验。这是这两个链接的答案:
那么我的问题是:在什么情况下,演示 / 测试环境和生产 / 稳定环境应该共用一个数据库服务器?还是我目前的公司和之前的公司做事方式不对 / 太过节省成本等等?
提前感谢您的回答。