I am looking for some best practise. We have a git repo set up for our database with two standard branches develop and master with appropriate branch policies for each. We use feature branches off of develop for new development. New development is done locally in the features branch and local db. When the features branch is pushed to the server, it is built and deployed to a development database in Azure for other developers to use during development. This is the first problem I see. Since the features branch is pushed to the server since it is not ready to be merged into develop via a pull request, there is no forced validation of any migration scripts (as would be done in a pull request) being released to the Azure development database which could cause additional migration scripts to be created and deployed. Now the developer could certainly request an informal code review from the dba before doing all of this, but that is on the honor system. And once a migration script is deployed, it can't be changed without causing drift. See the issue?
So without creating additional long lived branches that could have branch policies applied, how are people handing this situation to ensure migration scripts are as good as they can be in early stages of development?
This is a lot simpler in the .net world!
Thanks for any insight anyone can provide. Thanks