Keep tracking of database schema changes in microservices using that database

Question

We have a database used by legacy monolithic web application which is often changing by the team of database developers. Other dev teams have a task to pull out a lot of functionality of that legacy web app into ASP.NET Core 2.1 WebApi microservices. Each microservice uses that database and "database first" approach. So we have a lot of models in our microservices. But legacy web app living it's own life and it's database is often modified by db devs. So it's breaking our microservices models. We can't use migrations, because it will break our legacy web app which we cannot turn off for now.

So we decided to use "model first" approach and custom SQL Views, which implements such a contract between custom EF Core 2.1 QueryTypes and database tables. So if database developers will change database table, for example delete a column or change column type or something like that, they will reach a message telling that there is a view with that column so you couldn`t simply delete it. That approach gives us such a protection level for modifying that parts of schema which used in microservices models.

So legacy web app with its database definetely should be able to be modified because of the business needs. So legacy monolithic web app with its database is the prior. But these modifications are breaking our microservices models but of course we don't want it.

What is the best practice for handling such scenario?

Answer 1

That's a good question and this problem comes up a lot.

One option is cultural: implement a code review process where the DB devs need to create Pull Requests and can't push/merge a DB modification script and/or perform a release without a minimum of 2 approvals from the application developers.

If the db devs don't cycle changes through version control, and/or they are unwilling to recognize your need, and/or they are unwilling to cooperate in the process of cultural and process change (as good Agile/DevOps devotees ought to), then yes, you will need to consider other options.

Answer 2

I think that really what you have is a lack of communication between your two dev teams, and that is a much harder problem to solve. If you have devs from either team randomly running SQL scripts left right and centre then you are always going to have problems.

A decent technical solution is to maintain integration tests as part of a CI/CD pipeline. When a change is checked in to the Database project, also run a build and test for any affected microservice applications.

A failing test raises an immediate red flag for the microservices devs, and might even be able to prevent the changes being carried forward into your primary branch.