DevOps - Don’t Forget the DBA

The DevOps movement has been great at increasing inclusion among the various roles in IT, breaking down solos and creating groups capable of deploying code.  But one group seems to have been left out of the mix - DBAs.  For whatever reason, DBA tools have been slow to build in features synonymous with DevOps such as source control.

The Phoenix Project and DevOps Handbook spend a great deal of time discussing Flow and how a we’ll run organization will look to eliminate blockages at choke points.  Often these blockages occur during hand-offs.  The best way to avoid hand-offs is to build teams with all members needed to make a deployable package.

Traditional Teams have a manager over a set of like skilled workers.  Developers have their own managers, Testers have mangers, IT Ops staff have managers, etc.

Traditional_Team_Config_01.png

Modern teams reconfigure the members such that each team would have all the capabilites needed to deploy a product.

Dev_Ops_Teams_01.png

In addition to the team configuration, the software needs to be reconsidered too. Vendors such as Microsoft now offer an editor that includes source control tools allowing it to upload code to Github repositories.   The SQL Server Operations Manger software is a new application for the exemplifies was he new Microsoft.  The application is available on multiple OSes (Windows, Linux, Mac) and the source code is published on GitHub.  But also indicative of  the new Microsoft is the way it embraces current standards.  Git is almost universally recognized as the de facto standard of source control, and it’s a first class citizen in this app.

RedGate and DBMaestro also promote support of DBAs along their DevOps journey.  These apps offer additional controls and claim to help place the entire database under source control.  Teams should decide if this is the best path for them.