Database Web应用的退出计划

我们需要一个网络应用的退出计划，它的第一个维护版本即将投入生产。 我们面临的问题是，即使我们退出新的EAR并部署旧的EAR，使用新版本键入的数据也不会支持旧的业务规则（当前），因为业务规则中有巨大的变化。

---

你能建议我们如何解决这个问题吗？

这通常需要一个系统性的方法来限制你如何发展应用程序。例如，最好先进行模式更改，然后让它们友好地坐在旧应用程序中。然后，如果可能，将新系统与旧系统并行推出，并使用测试帐户进行测试。最后，您将以交错的方式向客户推出产品

---

在不了解应用程序的细节的情况下，我不能说这种方法对您来说有多可行，但我要说的是，在设计新版本的早期阶段，通常需要进行大量思考。

如果事先不了解系统，这是一个很难回答的问题。 旧数据是否有升级路径可以与新版本一起正常工作？ 如果是这样的话，你可能不需要担心。 您可能会遇到以下情况：

新版本非常糟糕，无法使用，必须回滚-没有值得一提的新数据将被输入，只需使用旧数据恢复旧版本

新版本还可以，有一些问题，您需要临时回滚-新数据将不可用，如果绝对必要，您可以手动调整其中一些，同时您的团队疯狂地修复新版本并重新部署

新版本很好，服务器崩溃-您只需从安装后所做的备份中恢复，并将所有新数据转换为使用新规则

---

新版本中没有架构更改。唯一的变化是一些业务规则的边界条件。例如，早期版本中允许的产品术语值为6年，现在为9年。如果用户在新版本投入生产后选择8年作为期限值，并且如果我们放弃更改，输入的数据将触发旧版本的应用程序。我们有一个预生产环境，系统正在测试中。但为了更安全，客户希望有一个退出计划。好的。为了让事情变得清楚，让我讲一个场景。根据旧的应用程序，一款产品允许的客户最大年龄是35岁，根据新的商业规则是40岁。假设一个客户做了一笔年龄为39岁的交易，这是旧规则不支持的。因此，如果客户对其帐户/交易进行任何维护，系统将是致命的。此外，在这种情况下，我们不能修改客户年龄以支持旧版本的应用程序。系统可以简单地标记坏数据，以便有人（人或非人）可以在处理之前处理它resumes@nobody：您能否举例说明在新数据上使用旧版本应用程序时的情况？