luc*_*iet 5 debugging production-environment
我一直在考虑这个问题.这个想法是PROD出了问题.捕获的数据导致Web应用程序的行为与其他环境不同.因此,其他环境中的数据也与prod不同步(如预期的那样).但是,出现了一个错误,由于某些原因,它只发生在PROD中,可能是因为数据存在差异.
我想知道解决这些问题的好方法是什么？肯定会有更多测试.但除此之外？可以在dev中创建新数据,但重点是某些数据点或某些操作组合会导致数据点出错.也许当使用其他数据源到达"实际"数据点时,这与"预期"数据点不同.道歉,这不是一个很好的描述,并试图成为一般生产bug的一个例子和定义.
我知道这不是一个非常精确的问题.希望有参考文献提出好的建议.
这是一个非常有趣的问题。我以前使用过的一种方法是有意在生产中进行最终测试 (TIP)。
在你用多根尖针刺穿我的雕像之前，请先听我讲一下持续部署:-)
这个想法是将新版本部署到生产中，然后使用自定义路由来引导新旧生产版本之间的流量。原则上，这非常简单：您首先将旧版本路由给当前客户，将新版本仅路由给您的工程团队。您的客户看不到任何变化。但您的团队可以开始测试您的新构建，包括灾难恢复和压力测试等混乱的内容。您有望发现您在问题中谈论的错误类型。
如果出现问题，您只需回滚新版本即可。如果您的测试没有发现任何问题，您就会向 5% 的客户群推出。然后是10%、20%等等。
虽然原则上很简单，但有些问题需要您从一开始就做好计划。第一个是数据和数据模式，它们需要在新旧版本中都能正确运行。只要您的 Web 应用程序使用的服务被设计为在部署新版本后至少处理一次回滚，并且您的新版本能够理解旧数据和新数据，那么您应该没问题。
第二个问题是API/接口的变化。您需要创建一个新的 API/接口，而不是编辑或删除方法或参数，该新的 API/接口主要重定向到旧的 API/接口，但新的/更改的代码除外。
其他问题包括版本之间配置和设置的不兼容更改。这些问题并不是致命的，但您确实需要事先进行一些规划和测试。最大的回报是您可以安全地在生产中对代码进行最终测试，而不会影响您的客户。
有关生产中测试的一些链接：
| 归档时间： |
|
| 查看次数： |
1741 次 |
| 最近记录： |