Beta测试新网站的功能,包括实时数据和真实客户

时间:2012-12-20 14:03:39

标签: php git cakephp testing beta

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

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

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

所以:

  1. 他们不必通过访问网站的复制版本来做两次。
  2. 他们正在使用熟悉的数据集
  3. 另一种可能性是为每个用户帐户设置一个标志,以允许他们查看某些功能,但这需要大量额外的工作。此外,一旦准备好发布,我们将不得不删除所有额外的检查。

    我很难看到这个的缺点,但我知道必须有一些瞪眼我。谢谢你的帮助。

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

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

    基于一些评论和一个答案,我根据反馈进行了更新。

    1. 应在'beta'/用户反馈测试之前进行细致的内部测试。 (我们已经做过)
    2. 如果我们采取这些预防措施并且代码库看起来很稳固,那么与生产服务器一起部署的风险可以控制。我们在这里的框架内工作,所以大规模删除和坏sql的可能性相对较低。
    3. 所有这一切,我宁愿采取这种方法,因为它仍然存在固有的风险。有人用其他方式对实时服务器数据进行beta测试吗?

1 个答案:

答案 0 :(得分:1)

这取决于......

如果这是一个获得客户反馈的测试版,对于经过全面测试并且已知稳定的产品,风险相对可控(尽管如下所示)。这是Google定义“beta”的方式。

如果“beta”意味着代码已完成,并且有点测试,但谁知道那里有什么错误,则可能会破坏您的实时数据库。无论您的备份策略多么聪明,如果出现问题,最好的情况是测试用户面临数据丢失或损坏;最糟糕的情况是你的所有用户都丢失了数据(我已经看到删除或更新语句中的“where”条款会造成各种娱乐损失)。

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

一般来说,处理单向兼容性要容易得多 - 允许用户升级但不降级 - “beta”的另一个强烈论据是“用户反馈”...