我们有一个使用ASP.NET MVC，C＃和MySQL编写的Web应用程序，并使用Entity Framework 6作为ORM。
我们正在使用Entity Framework的CodeFirst迁移来控制数据库随时间和从发布到发布的更改。
我们使用Jenkins设置持续集成/部署流程来创建构建工件（存档文件），该工件上传到AWS S3，并从那里开始组合Lambda函数和AWS的CodeDeploy负责部署应用于各种EC2实例。
每个EF Migration都有Up（）和Down（）方法，允许特定的迁移文件为应用程序代码的特定版本升级和降级数据库。
最近出现的一件事我们没有明确答案：
如何管理＆＃34;降级＆＃34;如果要重新部署以前版本的应用程序，请访问数据库？
由于应用程序版本（以及代码）较旧，因此任何新的EF迁移文件都不会包含在其中，因此，没有可以将数据库恢复到之前状态的Down（）方法因为Down（）方法都包含在以后的EF迁移中，现在它们不再是（旧版本的）应用程序代码的一部分。
我们经常不会使用旧版本的应用程序，但如果我们遇到无法预料的问题，我们可能会偶尔做些事情，并且我确信其他人不得不处理有效回滚/降级已由较新版本的应用程序升级的数据库。
有没有人有任何好的策略来处理数据库回滚/降级，理想情况是以最自动化的方式，理想情况下，使用与旧版本完全相同的先前构建工件（即无需完全＆＃34） ;重建＆＃34;旧版本？？
答案 0 :(得分：1)
这是一个有趣的话题，我希望在这里看到更多答案。由于目前还没有多少贡献，我只想转发我的想法。
根据我的经验，在执行数据库降级时并不总是有明确的答案。降级模式非常简单，可以执行一系列步骤，将模式下载到以前的版本。如前所述，EF迁移已具备此功能。 数据本身会带来麻烦。虽然某些数据可以进行版本控制（查找表，配置等），但绝大多数数据通常都不受版本控制和降级过程所带来的安全限制。因此，在应用降级脚本时，您可能会无意中从数据库中删除一些数据。当然，除非你的降级过程以降级时考虑数据的方式编写和测试。例如，如果要在升级期间将数据从一个表迁移到另一个具有不同结构的表，则降级过程将需要将数据迁移回来（如果可能）。在某些情况下，降级可能很困难或不可能，例如，如果从表中删除列。在这种情况下，您几乎需要从备份（至少该数据位）进行恢复，因为删除列会破坏该列中的数据。
过去，我发现查看降级所做的更改会有所帮助，并根据需要进行自定义。实际上，大多数情况下，您可能会发现数据库降级甚至不是必需的，并且您的应用程序将在数据库更改完好的情况下正常运行。
答案 1 :(得分：0)
这是一个很长的镜头但您是否尝试过更改连接字符串？听起来太简单了，但如果表格相同的话。 。 。 。