5

I would like to run blue green deployments; however, EF Migrations seem to block that. If I deploy version 1 to the Blue slot, create an EF Migrations and deploy version 2 to the Green slot, then one of two things will happen.

Scenario 1:

I will have run the migration, and version 1 will stop working. This defeats the purpose of being able to test version 2 in the green slot while letting our users run version 1 in the blue slot.

Scenario 2:

I don't run the migration until I switch from the blue slot to the green slot. This means that I can't test the green slot (version 2) before giving users access to version 2.

What is the standard/best practice for handling this?

TheAlgorist
  • 123
  • 5

1 Answers1

5

For workflows like this, you need to make schema changes in two steps.

The first step is to add everything you're going to need for v2 in a way that is compatible with v1. Any new column will need to be optional or, if possible use a default constraint or trigger to populate it based on v1 values.

Once v1 is retired, you can clean up the schema by removing unused columns and making columns required.

NuGet.org has been successfully using this workflow via EF migrations for many years.

bricelam
  • 28,825
  • 9
  • 92
  • 117
  • We have EF 6 and EF Core applications we are moving to containers on a cluster. Is there anything besides staying backward compatible in phase 1 that needs to be done? Any specific EF configuration settings or gotchas with timing? – MikeJansen Oct 05 '21 at 19:17
  • 1
    @MikeJansen Run migrations as part of the deployment process. Don't do it on app startup or bad things will happen when two clients try to update the database at the same time. – bricelam Oct 05 '21 at 20:54