重新部署旧版本应用程序数据库的策略
本文关键字：应用程序 版本 数据库 策略 新部署 部署 | 更新日期: 2023-09-27 18:13:32
我们有一个使用ASP编写的web应用程序。. NET MVC, c#和MySQL，并使用实体框架6作为ORM。
我们正在使用实体框架的CodeFirst迁移来控制数据库随着时间的推移和从一个版本到另一个版本的变化。
我们有一个持续集成/部署过程，使用Jenkins创建一个构建工件(存档文件)，并将其上传到AWS S3，然后Lambda函数和AWS的CodeDeploy的组合负责将应用程序部署到各种EC2实例。
每个EF Migration都有Up()和Down()方法，允许特定的迁移文件为特定版本的应用程序代码升级和降级数据库。
最近出现的一件事，我们没有明确的答案是:
如果您重新部署应用程序的前一个版本，您如何管理数据库的"降级"?
由于应用程序版本(因此代码)较旧，任何新的EF迁移文件都不会包含在其中，因此，没有Down()方法可以将数据库恢复到以前的状态，因为Down()方法都包含在后来的EF迁移中，现在不再是(旧版本的)应用程序代码的一部分。
我们不经常恢复到旧版本的应用程序，但如果遇到不可预见的问题，我们可能偶尔会这样做，而且我相信其他人必须处理有效的回滚/降级已经被新版本的应用程序升级的数据库。
是否有人有任何好的策略来处理数据库回滚/降级，理想情况下，以尽可能自动化的方式，并通过，理想情况下，使用完全相同的以前的构建工件为旧版本(即不必完全"重建"旧版本)?
这是一个有趣的话题，我希望在这里看到更多的答案。由于还没有很多贡献，我只是想传达我对这个问题的看法。
根据我的经验，在执行数据库降级时并不总是有一个明确的答案。降级模式相当简单，可以执行一系列步骤将模式降级到以前的版本。如前所述，EF迁移已经具备了这种能力。问题出在数据本身。虽然有些数据可以进行版本控制(查找表、配置等)，但绝大多数数据通常不在版本控制和降级过程所施加的安全范围之内。因此，在应用降级脚本时，您可能会无意中从数据库中删除一些数据。当然，除非您的降级过程是以这样一种方式编写和测试的，即在降级时将数据考虑在内。例如，如果在升级期间将数据从一个表迁移到具有不同结构的另一个表，则降级过程将需要将数据迁移回来(如果可能的话)。在某些情况下，可能很难或不可能降级，例如，如果从表中删除一个列。在这种情况下，您几乎需要从备份中恢复(至少是那位数据)，因为删除该列将破坏该列中的数据。
在过去，我发现查看降级所做的更改并在必要时进行定制是很有帮助的。实际上，很多时候您可能会发现甚至没有必要降级数据库，并且您的应用程序可以在数据库更改完整的情况下运行得很好。
这是一个很长的镜头，但你试过只是改变连接字符串吗?听起来简单得令人难以置信，但如果表是相同的. . . .