Why I like the Release Flow branching strategy with Git for database DevOps

When people begin applying DevOps principles to database development using Redgate tooling, often one of the first steps in the process involves getting database code into version control. Questions naturally come up about how to manage the flow of changes to database objects from development into production once changes begin occurring.

When using Git for version control, branches are a huge help when it comes to managing this flow.

But how do you use branches? It’s helpful to pick a strategy. There are many fine Git branching strategies out there, things like GitFlow and GitHub Flow and more – enough that it’s overwhelming to learn about these when you are just starting out.

The strategy that I recommend for folks who are starting out with database DevOps and Git is the Azure DevOps team Release Flow model with dedicated development databases. (Why dedicated development databases? Read more here.)

Why the Azure DevOps Release Flow model fits databases well

• Topic / feature branches provide a place for experimentation
• Pull requests provide communication, feedback, and review – a prime collaboration point for developers and DBAs for many teams
• Code can be merged into the main code line without being deployed automatically (for databases, where rollbacks are often anything but straightforward, immediate deployment isn’t always grand)
• Releasing at sprint milestones using a branch created for deployment often makes the most sense

Further, the release flow model can support both small and large teams.

Look! I drew a picture

There are absolutely exceptions where other models make sense

For instance, for those who have implemented a microservices model with robust automated testing in place, it may be more suitable to do something like a modification of the GitHub flow branching strategy.

But that’s not the case for most folks – most folks have databases which are more complex, with cross-database queries and downstream dependencies galore. For these more ordinary databases, the Azure DevOps Release Flow model is a really great place to begin.