I wrote once previously about how I used EF Core migrations to upgrade production database. I have two slots production and staging and I swap them every time I push new code that don't involve database changes. This week I had to make a data change to production database, it's a reminder of when to use the Swap with preview feature provided by Azure App Services.
I recently decided to change versioning scheme a bit in hope to turn out releases more often, so the upcoming release originally planned as v1.1 has now become v2.0. As a result, I opened up issue #235 EF Migration and SQL upgrade files got wrong version numbers to fix the out dated text in these files.
In addition I need to update a record in the __EFMigrationsHistory table, specifically it’s the second row’s
MigrationId needs to become "20180530163323_FanV2_0".
To update this record I can run a simple SQL update statement while the site still running, because EF only checks this table every time the application starts up to see if there are new migrations need to be applied. The challenge is I don’t want a request hit the database before the new code gets there, because the existing code looks for the "20180530163323_FanV1_1" record and if it’s not there it’ll apply migration thus causing problems.
When using Swap with preview, these are the steps to take place:
1. First get staging database and server ready with new data and code (since it’s staging I can just stop the server and do whatever so that’s easy).
2. Update production database with the data change (the production site is still running).
3. Start the swap with “Swap with preview”, this will apply all production configurations to staging slot while still keep production running. It seems you can do this in either slot now, I somehow remember the option was only available in production slot previously.
4. Azure then restarts staging using these production configurations, now staging runs against production database which is OK since staging has the new code.
5. Finally do “Complete swap”, Azure moves the already warmed up staging slot into production.
In conclusion I could do this because it was only a data change. Consider if there were schema changes then you may not be able to update the production database first while production service is still running, in that case I'd refer to my previous post.