When implementing any kind of automation for database deployments, it’s important to implement safeguards for your production environment. This is needed even in the best conditions when team members collaborate well and there is a high level of trust, for a very simple reason: accidents happen easily!
I asked a question on Twitter yesterday: “If running SQL Server 2008 in an Azure VM (no SQL upgrade possible, extended support in place), is the best option for high availability Database Mirroring? Or something else I am not thinking of? #sqlhelp”
In this 70 minute livestream recording, I kick the tires of a fresh new Azure DevOps demo environment showing Redgate’s Hybrid Model for SQL Source Control and SQL Change Automation.
One of most the fun things about working as an Advocate at Redgate is getting to help clients determine their preferred workflow for database DevOps.
Teams often have unique requirements and are using different combinations of tooling, so figuring out the best way to accomplish what they need typically involves leveraging what I already know, collaborating with my coworkers and the client to generate ideas, researching and prototyping solutions, and then getting feedback from everyone.
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.
I’ve learned a bit about Git in the last year: I’m now quite comfortable creating and managing Git Repos in Azure DevOps. I frequently do demos with SQL Change Automation and SQL Source control with Git on Redgate’s YouTube channel, and I’ve published a Git Cheat Sheet for the Command Line Interface.
In this 35 minute livestream recording, I commit conflicting code to a Git repo in Azure DevOps Services using Redgate’s SQL Source Control, then step through options to fix the conflict.
We first run through an example where we hit a conflict when pushing to the master branch and resolve that. Then we run through an example where we are using a feature branch and identify the conflict when doing a pull request to merge the change into master.
Copyright (c) 2025, Catalyze SQL, LLC; all rights reserved. Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.