为什么要在sprint测试期间测试向后兼容性？

Question

例如，现在我们完成了sprint 10的开发，并希望在Stage环境中开始测试sprint测试。

我被告知，我们应该先测试'Sprint 10前端从舞台‘与'Sprint 10后端从舞台’。(我知道我们为什么要这么做)

然后测试'Sprint 9前端从生产‘与'Sprint 10后台从舞台’(不知道为什么我们需要这样做)。难道他们不会只得到后端前端10和后端10 )

Answer 1

还测试“Sprint 9前端从生产”与“Sprint 10后端从舞台”

如果您想要分离前端和后端部署，这是一个重要的测试案例，如果您想执行滚动部署(即在不停机的情况下增量地部署sprint 10后端)，这是必要的。通常情况下，首先部署后端，所以如果将spring 10后端部署到生产中，它将暂时是spring 9's前端和spring 10's后端的混合物，直到sprint 10前端部署到生产中为止。因此，您需要测试这个案例。

难道他们不只是得到后端前端10和后端10共？

您可以同时部署后端和前端，但这将导致用户停机，相当于停止所有前端和后端服务器、部署sprint 10工件以及启动前端和后端服务器。

如果sprint 10的后端不能支持sprint 9前端，会发生什么情况？

只有当您的sprint 10后端更改破坏了接口时，才会出现这种情况。例如，您决定从后端删除一个API方法，或者以一种中断的方式更改对象模型。在这种情况下，您有一些选项：

• 将前端或后端更改为兼容版本9和10。如果您从后端10中的API中删除了一个方法，您可以先从前端删除该功能(在9.1中说)，然后部署它，然后部署您的新后端。或者，您可以在后端临时添加一些内容，以支持两个前端版本。一旦前端和后端在同一个版本上，兼容性代码就可以被删除。
• 占用停机时间，同时部署前端和后端。