Should I use different Source Control repositories for Application and Database migrations?

I am working with my development teams that currently use EF Core Code First to create their database tables for applications development. We are working to incorporate source control on the databases so we can appropriately control all other database object changes. They have a repository for their code, does it make sense to have a separate repository for the databases? If so, how do you maintain that feature and database changes get deployed together. We think that we can use the same repository and branch database changes separate from feature branches. Would like to know if anyone else is doing this method to source control Database changes.

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

KenJ commented · Feb 28, 2019 at 11:53 PM

Does the database support other applications?

If your applications are coupled in this manner you may have little choice but to version the database independently of the applications it supports.

It would be ideal if the application and database could be versioned/branched together but that falls apart when multiple systems rely on the same shared resource.

0 ·

AaronUrfer commented · Mar 01, 2019 at 02:01 PM

@KenJ We have segmented our applications by knowledge domain and so they should be individual databases for individual applications. If any other application would need to do a read to another database, they would make those calls via API. Thanks for the response!

0 ·

Show more comments