这个问题的主要目标是确定在实际网站旁边部署网站的略微修改版本的陷阱。
这个二级网站将从与实时网站相同的数据库中提取数据，但会针对 Beta 测试人员修改功能。
最终目标是允许某些客户使用他们的数据测试我们的新功能。
所以:
- 他们不必通过访问网站的复制版本来执行两次操作。
- 他们使用熟悉的数据集
另一种可能性是为每个用户帐户设置一个标志，以允许他们查看某些功能，但这需要大量额外的工作。此外，一旦它准备好发布，我们将不得不删除所有额外的检查。
我很难看出这样做的缺点，但我知道肯定有人对我怒目而视。感谢您的帮助。
Git 版本控制、Capistrano 部署工作流、Cakephp 框架、MySql 我们目前拥有与生产服务器分开的本地和测试服务器。
编辑 2012 年 12 月 20 日美国东部时间上午 10:30
根据一些评论和一个回答，我根据反馈进行了更新。
- 应在“测试版”/用户反馈测试之前进行细致的内部测试。 (我们已经这样做了)
- 如果我们采取这些预防措施并且代码库看起来很可靠，那么与生产服务器一起部署的风险就可以控制。我们在这里的框架内工作，因此大量删除和错误 sql 的可能性相对较低。
综上所述，我宁愿不采用这种方法，因为它仍然存在固有风险。有人用其他方式对实时服务器数据进行 Beta 测试吗？
最佳答案
这取决于...
如果这是获取客户反馈的 Beta 版，在经过全面测试且已知稳定的产品上，风险相对可控(尽管请参见以下几点)。这就是谷歌定义“测试版”的方式。
如果“测试版”意味着代码完整，并且经过了某种程度的测试，但谁知道其中有什么错误，您就有可能破坏您的实时数据库。无论您的备份策略多么巧妙，如果出现问题，最好的情况是测试版用户面临数据丢失或损坏；最坏的情况是您的所有用户都丢失了数据(我已经看到删除或更新语句中损坏的“where”子句会造成各种娱乐性损害)。
另一个需要考虑的问题是数据库是否在版本之间向后和向前兼容 - 如果您的 Beta 用户不喜欢升级，或者出现问题，您能否将他们迁移回主流版本？当然，如果“beta”的意思是“未测试”，那么这就大得多了。
一般来说，处理单向兼容性要容易得多——允许用户升级，但不能降级——“测试版”意味着“用户反馈”的另一个有力论据……
关于php - 使用实时数据和真实客户对新网站功能进行 Beta 测试，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13973876/