I’ve written my fair share of configurations, scripts, and variants of autoexec-dot-bat files (remember those?) for a number of systems. Creating these sorts of artifacts (the source files) is part of being a responsible systems administrator, since the role requires being extended in multiple directions while trying to accomplish a diverse set of tasks. I’ve noticed, however, that most operations folks (my former self included) tend to stash their artifacts on a shared drive located on a workstation or NAS instead of using a proper version control system. When I bring this up as a red flag to other administrators, I usually hear something like …
Version control is used for source code that my developers write! They use fancy sounding things like Team Foundation Server (TFS), Subversion (e.g. TortoiseSVN), or dusty old witchcraft like Visual SourceSafe (VSS). I don’t need that sort of higgledy-piggledy in my day-to-day world … blarg!
Regardless of the team size, holistic use of version control is one of the pillars in building a DevOps-focused culture. It allows for truly interactive experience, enables a learning-from-failure feedback loop, and empowers both sides of the aisle (business development to operational teams) to take ownership of server and application configuration. There are many systems available, although I tend to lean on GitHub to catch, learn, and grow from my mistakes in the lab. As an added bonus, I keep the repositories public so that others can follow along with my journey, although there’s the option to use private or on-premises flavors for organizations that aren’t comfortable or permitted to publicly share or use a SaaS based offering.
Stashing artifacts into a version control system has another huge and often overlook benefit: experimentation. Any versioning system worth its salt will allow for branching, which is similar to the concept of creating a linked clone of a virtual machine. Any changes made to the branch code version (linked clone) are independent of the main code version. If the experiment fails, you can blow away the changes and try again. If the experiment succeeds, you can merge (pull) changes into the main code version or even continue to experiment until you’re happy with the changes. Additionally, other team members do the exact same thing along their own branches without too much fuss over stepping on each other’s toes.
If you’re writing scripts, configuration files, or anything else to describe the state of an application or server, I highly suggest talking to your team about using a version control system. It’s a little painful to learn at first, and you’re going to buck against some of the terminology, but the end result is highly rewarding.
