DevOps has been a buzzed word in the IT space for a while now. In case you are unfamiliar, DevOps is the conceptual marriage between Developers and IT Operations. The idea behind DevOps is to facilitate communication and collaboration via cross-department integration, which is a crude way of saying the barriers between operations and developers are being broken down/stripped. While the concept of DevOps is not new, bringing databases into DevOps is, or rather, maybe to me it is.
From a production DBA standpoint, it can be difficult to wrap your mind around how to apply DevOps concepts to your existing environment. This is where one should perhaps watch a webinar or catch a session at an SQLSaturday. I caught Steve Jones’s presentation on DevOps at the Colorado Springs SQL Saturday which really helped me wrapped my head around it, as well as gave me some ideas on how to apply it. One of the DevOps concepts that have really resonated with me is source control.
DBAs have a ton of scripts that are used from report building to performance tuning, and whatever else that they can solve. Over the years, and over teams, these scripts get updated and changed. Source control is an excellent way to keep versions as well as share across the team. It’s an even better way to maintain scripts when multiple team members are working together to develop a stored procedure(s) or large piece of code.
While I am very much new to DevOps and source control. I am definitely working towards understanding its nuances and figuring out how to implement it at the office. I have managed to set up both a repository at both GitHub and Visual Studios Team Services through Dev Essentials. Although now that I have the repositories set up, I still need to find the bandwidth to figure out how to check code in and out via SSMS. Once I have that completed and thoroughly tested, I can take that information to my team and begin using source control in the office.