Strategies for redeploying an old version of your application database

Question

We have a web application written using ASP.NET MVC, C # and MySQL and using Entity Framework 6 as ORM.

We use the Entity Framework CodeFirst Migrations to manage database changes over time and from release to release.

We have a continuous integration / deployment process created using Jenkins to create an assembly artifact (archive file) that loads into AWS S3, and from there the combination of the Lambda and AWS CodeDeploy functions is responsible for deploying the application for various EC2.

Each EF migration has both Up () and Down () methods that allow a specific migration file to update and lower the database for this particular version of the application code.

One thing that has recently appeared and for which we do not have a clear answer:

How do you manage database downgrades if you redeploy a previous version of your application?

Since the version of the application (and therefore the code) is older, any new EF migration files will not be included in it, therefore there are no Down () methods that can return your database to its previous state as Down () are all included in later EFs migrations, which are now no longer part of the application code (older version).

We don’t often go back to older versions of our application, but we can sometimes do this if we have unforeseen problems, and I’m sure that others had to deal with efficient rollback / downgrade of a database that was updated with a newer version of the application.

Does anyone have good strategies for working with database rollbacks / downgrades, ideally in the most automated way and, ideally, using the same previous build artifact for an older version (i.e. without the need to completely “rebuild” ) old version)?

Answer 1

This is an interesting topic, and I was hoping to see a few more answers here. Since there is still not much, I just wanted to convey my thoughts on this matter.

In my experience, when performing a database downgrade, there is not always a clear answer. The transition to the scheme is quite simple, and you can perform a number of steps that can lead to the fact that the scheme will be transferred to the previous version. As already mentioned, EF migration already has this capability. The problem is with the data itself. While some data may be versions (lookup tables, configuration, etc.), the vast majority of data usually goes beyond security imposed by version control and downgrade process. Thus, when applying a downgrade script, you may accidentally delete some data from the database. IF, of course, your downgrade process is recorded and verified in such a way that it considers the data during the downgrade. For example, if you transfer data from one table to another with a different structure during the update, your downgrade process will need to transfer the data back (if possible). In some cases, it can be difficult or impossible to downgrade, for example, if you remove a column from the table. In this case, you will almost need to restore from the backup (at least this bit of data), since deleting a column will destroy the data in that column.

In the past, I found it useful to consider the changes that will be made as a result of the downgrade and adjust them as needed. In fact, most of the time you will probably find that lowering the database is not even required, and that your application will work fine with modifying the database.

Answer 2

This is a long snapshot, but were you trying to just change the connection string? It sounds too simple to be true, but if the tables are the same. ,,