2

这个问题的主要目标是确定在实时网站旁边部署稍微修改过的网站版本的缺陷。

这个辅助网站将从与现场相同的数据库中提取，但会为 beta 测试人员修改功能。

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

所以：

  1. 他们不必通过访问该站点的复制版本来做两次事情。
  2. 他们使用熟悉的数据集

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

我很难看到这样做的缺点，但我知道一定有一些人在盯着我看。感谢您提供任何帮助。

Git 版本控制、Capistrano 部署工作流程、Cakephp 框架、MySql 我们目前拥有独立于生产服务器的本地和测试服务器。

编辑 2012 年 12 月 20 日上午 10:30 EST

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

  1. 在“beta”/用户反馈测试之前应该进行细致的内部测试。（我们已经这样做了）
  2. 如果我们采取这些预防措施并且代码库看起来很稳固，那么与生产服务器一起部署的风险是可以控制的。我们在这里是在一个框架内工作，因此大量删除和坏 sql 的可能性相对较低。

话虽如此，我宁愿不采用这种方法，因为它仍然存在固有风险。有没有人以另一种方式对实时服务器数据进行 beta 测试？

4

1 回答 1

1

这取决于...

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

如果“beta”意味着代码完整，并且经过某种程度的测试，但谁知道那里有什么错误，那么您可能会破坏您的实时数据库。无论您的备份策略多么巧妙，如果出现问题，最好的情况是测试版用户面临数据丢失或损坏；最坏的情况是您的所有用户都丢失了数据（我已经看到删除或更新语句中损坏的“where”子句会造成各种有趣的损害）。

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

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

于 2012-12-20T15:00:10.417 回答