Question - EFCore migrations in production

[edwinvw]

Question - EFCore migrations in production

[EdwinVW]

Thanks @Thwaitesy for your interest in the project!

The scenario you describe is indeed something that I don't support with the current implementation. So you're not missing anything.

It would be a nice addition though, because backward compatible DB migrations are indeed one of the nastiest issues to tackle with zero-downtime deployments. I'll think about adding this to the project.

Thanks for the heads-up!

[Thwaitesy]

Ok cool, yeah I was just looking through things and was like.. mmm maybe ive missed some magic migration feature haha.

In no way am I saying you should add this particular feature to your project, but for anyone reading along and want to know how I solve the issue then here it is:

I have a seperate project/console app which has all the migrations in it which is basically the below program.cs file.

I can then call that app as part of my deployment like so: Api.Database.Migrations.dll <insert-db-connection-string right before I deploy to x machines/pods. Obviously all db changes need to be backwards compatible, so no renaming or removing tables & columns etc until they are not being used. Its not hard, it just needs planning.

program.cs

namespace Api.Database.Migrations
{
    public class EFCoreContextFactory : IDesignTimeDbContextFactory<EFCoreContext>
    {
        public EFCoreContext CreateDbContext(string[] args)
        {
            var connectionString = args != null && args.Length == 1 && !string.IsNullOrEmpty(args[0]) ? args[0] : "Data Source=(local);Initial Catalog=DatabaseName;Integrated Security=True";
            var optionsBuilder = new DbContextOptionsBuilder<EFCoreContext>();
            optionsBuilder.UseLoggerFactory(Program.CustomLoggerFactory);
            optionsBuilder.UseSqlServer(connectionString, opt => opt.CommandTimeout(120)
                                                                    .MigrationsAssembly("Api.Database.Migrations"));
            return new EFCoreContext(optionsBuilder.Options);
        }
    }

    class Program
    {
        public static readonly LoggerFactory CustomLoggerFactory = new LoggerFactory();

        static void Main(string[] args)
        {
            //Setup Logging
            Log.Logger = new LoggerConfiguration()
                .MinimumLevel.Verbose()
                .WriteTo.Console()
                .CreateLogger();

            CustomLoggerFactory.AddSerilog(dispose: false);

            try
            {
                Log.Information("Preparing to migrate database.");

                using (var db = new EFCoreContextFactory().CreateDbContext(args))
                {
                    db.Database.Migrate();
                }

                Log.Information("Finished migrating database.");
            }
            catch (Exception ex)
            {
                Log.Error(ex, "Error migrating database.");
                Environment.Exit(1);
            }
            finally
            {
                Log.CloseAndFlush();
            }
        }
    }
}

Anyway I hope that provides some use to someone 👍

[davidhenley]

@Thwaitesy @EdwinVW would it also make sense for all of the db writes go to one database or is this standard for containerized systems?

I've never used multiple databases for one app. Wouldn't you have a lot of cross-database joins for reporting purposes? Does this not affect db performance?

[EdwinVW]

@Thwaitesy I always have a separate database (or databases) for every Microservice. This is mainly because you want your services to be as autonomous as possible. That is why these databases are even made completely inaccessible from outside the service (also not for reporting!).

For reporting I would introduce a separate database that has read-models specifically for reporting purposes and fill these models by ingesting all the events that are emitted by the services.

[davidhenley]

OK, thanks. I'm trying to learn how to build using microservices, but am having a tough time learning Ocelot, Messaging, etc all at the same time. Your repo is very helpful, and I hope to grasp it all someday soon.