Branching & Merging Strategy for Redgate Deploy (Flyway)

We are implementing databases code changes automation using Redgate Deploy (Flyway) + Azure DevOps for SQL Server databases. 

We are thinking having: master ==> development ==> "feature branches", and delaying migrations creation until merging with  "development" and approve code reviews, to finally merge with "master" to trigger pipeline actions (build and then deploys).

However, somebody in the project team started to talk about the importance to keep "master" branches as images of production databases, which would imply merge with "master" only after changes are deployed to production and force to create a another branch sat in the middle between "master" and "development" to move migrations for pipelines actions. Is that the right approach? Is there a cookbook somewhere on how is the best way to implement?

Thanks in advance!



Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file