Php 使用实时数据和真实客户测试新网站功能

此问题的主要目的是确定在实时网站旁边部署稍加修改的网站版本时的陷阱。

这个二级网站将从与live相同的数据库中获取，但将为beta测试人员修改功能

最终目标是允许某些客户使用他们的数据测试我们的新功能

因此：

他们不必两次访问复制版本的网站

他们正在使用熟悉的数据集

另一种可能是为每个用户帐户设置一个标志，以允许他们查看某些功能，但这需要大量额外工作。此外，一旦它准备好发布，我们将不得不删除所有额外的检查

我很难看出这样做的缺点，但我知道一定会有人对我怒目而视。谢谢你的帮助

Git版本控制，Capistrano部署工作流，Cakephp框架，MySql 目前，我们的本地服务器和测试服务器与生产服务器分开

编辑2012年12月20日美国东部时间上午10:30

根据一些评论和一个答案，我有一个基于反馈的更新

在“beta”测试/用户反馈测试之前，应进行细致的内部测试。（我们已经做到了）

如果我们采取了这些预防措施，并且代码库看起来很可靠，那么在生产服务器旁部署的风险可能是可控的。我们在一个框架内工作，因此大规模删除和坏sql的可能性相对较低 尽管如此，我宁愿不采取这种方法，因为它仍然存在内在风险。有人用另一种方式对实时服务器数据进行beta测试吗？

这取决于

如果这是一个获得客户反馈的测试版，对于一个经过全面测试且已知稳定的产品，风险相对可控（尽管见下文要点）。这就是谷歌定义“beta”的方式

如果“beta”意味着代码已经完成，并且经过了测试，但谁知道里面有什么bug，那么您就有可能损坏您的实时数据库。无论你的备份策略多么聪明，如果出现问题，最好的情况是测试版用户面临数据丢失或损坏；最糟糕的情况是，所有用户都会丢失数据（我看到delete或update语句中被破坏的“where”子句会造成各种各样的破坏）

另一个要考虑的问题是数据库是否在版本之间向后兼容和向前兼容。如果他们不喜欢升级，或者如果出了问题，你能迁移你的beta用户回到主流版本吗？当然，如果“beta”意味着“未经测试”，那么这将是一笔更大的交易

---

一般来说，处理单向兼容性要容易得多——允许用户升级，但不允许降级——另一个强有力的论据是“beta”意味着“用户反馈”…

如果它仍然是beta代码，可能会因为尚未完全测试的代码而丢失数据。在同一个数据库上，这可能是一个问题。Beta代码绝对不应该在生产数据库上运行。它可能工作正常，但可能会使您的数据库陷入混乱，一旦您的客户决定不喜欢/不需要这些功能，您就无法返回。话虽如此，如果您修改的主要是UI，并且底层功能相同，我想您甚至可以实现它。如果您希望测试人员在live数据库中进行更新，您可以考虑一些数据复制，但我认为这不是个好主意。像谷歌这样允许测试人员使用新界面的网站呢？我记得当新的分析发布时，我可以很容易地在两者之间切换。他们肯定有一些不同。。。你知道他们是怎么做到的吗？你应该还有一个开发、演示/测试和实时服务器。即使是谷歌实验室的功能在启用之前也会经过严格的内部测试。也就是说，您仍然可以有一个与同一数据库交互的beta版接口，但只有在它经过其他测试周期之后，才可以使用它。这与我们正在努力实现的目标更接近。我们做我们自己的内部测试，并可以验证我们的测试环境中的一切工作，但我们需要真正的用户给我们他们的想法。