By now you have most likely heard the term DevOps and you are most likely working for a company that has implemented DevOps is some manner, that could be infrastructure, applications or database to just name a few. However, Database DevOps is one of the least implemented processes in the entire DevOps stack as of the time of this post.
So why is database DevOps lagging so far behind?
Well for the longest time that answer was simple and it was because as compared to AppDev and Infrastructure the tooling around Database DevOps was almost non existent or seriously lacking in functionality and performance. That is no longer the case though as there are quite a number of tools on the market now, but before I begin shamelessly plugging tools lets get back to the title of this post.
Where do I start?
This seems like a rather easy question on the surface but is it really? Of course it’s not otherwise why would I be writing this. So lets start with what I call the 5 Keys to DEVOPS success.
- Buy-in from Upper Management
- Collaboration with internal teams
- Proven Tooling
- Training, Training and more Training
- Thick skin (You are going to face resistance)
Let’s touch on each of these briefly.
Buy-In from Upper Management
You will have obstacles and things won’t go 100% smoothly, trust me. This is where you need the buy in from all the way up so that when you do hit that bump in the road management isn’t running for the hills saying I told you so. I personally imagined some of my developers singing their own version of Hamilton’s “Washington on your side” but singing “It must be nice to have the CTO on your side”
Collaboration with internal teams
From my experience many developers still have not worked within a Database DevOps framework and collaborating with the internal teams to understand their needs and create a collaborative environment will be crucial to getting total buy in from everyone. One of the most important teams to collaborate with is your DBA team, since they hold the keys to the castle.
Proven Tooling
Make sure that whichever tool you choose it’s one that has a proven track record of success and has good vendor support behind it. When the 
hits the 
you want someone to call and help work through any issues. If you do choose to build it out on your own just be prepared and have a solution to providing support.
Training, Training and more Training
Provide your team with training and not just generic training, training that is specific to the tooling and processes you are putting in place. I learned the hard way that generic training on source control or build tools just will not cut it. Design training sessions that will answer specific questions people have to the processes you are implementing.
Thick Skin
Here might the most important thing of all. You will need thick skin because you will get people fighting you, try to go around the process and in some cases straight up sabotage the project. Use the QTIP (Quit Taking It Personally) approach and let it roll off your back and keep fighting the good fight.
What comes next?
Now we move on to some of the slightly more technical things you want to make sure that you handle. While culture and process are a large part of the first steps and overall success there are some items you want to make sure that you are taking care of from the technical side too. While most of my experience is in launching DevOps for Microsoft SQL Server the items I am going to list out here are applicable for many different platforms. So here we go!!
Removing invalid objects
In many cases where there is no DevOps or standardized procedures in place invalid objects start getting left behind. If you are not familiar with this concept it’s when Functions, Stored Procedures, Views etc.. become invalid overtime as they are not being actively used and underlying tables change. It leaves you in a state where you have invalid objects in your database, and these will cause you a huge headache when implementing Database DevOps so get rid of them before you start.
- Choose your branching strategy
Branching Strategy is important and there isn’t any right one that fits all situations. First you need to understand what the business process around your promotion process is. For example, if your database is single tenant, supports a single application and has iterative releases then following a single branch git-flow model will most likely work for you. If you have a multi-tenant database, with non-iterative releases and multiple applications then a multiple fixed branch approach that allows you to cherry pick your releases may be appropriate.
- Create a baseline
I see this step skipped in many implementations and it almost always leads to a lot of sleepless nights. Creating a baseline of your database and making sure that baseline is valid is extremely importing. Easiest way I have found to do this is reverse engineer your database out, put it into source control then deploy it to a blank database. This will tell you quickly if your baseline is valid.
- Choose the right IDE/Toolset
Choose an IDE that your team is familiar working with and then find the DevOps framework that works best with that IDE. I know this may not be the popular opinion on this subject but from experience not making the teams switch IDE’s is going to be critical for adoption and success. For example, if you use SQL Server and most of your team is very familiar with SSMS as your IDE then take a look at Redgate’s Automated Deployment tools. I am only recommending this as it’s a toolset that I have implemented with great success.
That wraps up this Post if you want to learn more feel free to contact me or check out this video where I talk about Database DevOps. https://www.red-gate.com/hub/events/online-events/mizuho-launching-our-database-devops-journey