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.

4 Comments. Leave new

  • […] Kendra Little explains why the Azure DevOps Release Flow model can work well for database activity: […]

  • […] approach here can be a simple modification to an implementation of the Azure DevOps Release Flow branching strategy I wrote about last week — it’s a way to use feature branches with automatic reviewers. […]

  • I wish when talking about the dedicated dev database model people would address the issue with large databases, hipaa compliance, etc. It is a lot of work to make this a reality with those kinds of DB’s. And yeah I know Redgate has more tools they want to sell you for that, but they don’t work well in every environment or in everyone’s budget.

    • There’s a couple of different ways to handle this. One is with tooling — and this isn’t a sales pitch, there is all sorts of tooling out there which helps with this, and given the licensing people pay for their SQL Servers and the price people pay for SANS already, half the problem is folks not asking for a better way to do this when infrastructure discussions occur.

      The other way to handle this is simply to not use the entire large database or the production data at all stages of the development pipeline. A smaller, generated dataset can be extremely useful for quick iterations of development early in the process. More realistic datasets are definitely valuable, but when they aren’t feasible to use throughout the process they can be leveraged later in the process and managed differently.

      I find that in general the problem is not dataset sizes or compliance issues: it’s folks simply doing things they way they always have due to inertia.


Share a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: