Yeah, I know, it’s surprising me comment two days in a row. I’ve been “out of sorts” for the past little bit but I set myself a challenge recently that I intend to see through. I recently started reading the book “Accelerate: Building and Scaling High Performing Technology Organizations” and I really wanted to share the results with you.
The authors behind the book have been doing the “State of DevOps” reports for the past few years and have gathered an amazing amount of information and statistics to back up their statements. According to their data there are 24 key capabilities that drive performance in the software delivery organization.
Those 24 capabilities have been grouped into five larger categories. So, the challenge I gave myself was to give you one of these capabilities every day, although I would recommend picking up the book and reading it for yourself.
The first category is “Continuous Delivery”. This concept is all about getting features into the hands of users as quickly, as safely and as reliably as possible. While the ultimate in continuous delivery would be releases on an as needed basis (weekly, daily or even hourly), the concept can be complete by delivering on an “as needed” basis regardless of the time frame.
So, what’s the first thing that we’re going to look at? Version Control.
Version control is more than just putting your source code in a version control system. It is about putting everything that ends up creating the end product into the version control system. Source code? Version it. Application configurations (config files)? Also in version control. Database scripts? Version those suckers. The scripts used to build the application? Same thing. System configurations? Also in version control.
What it comes down to is this: someone should be able to take the information from the version control system and completely rebuild the system from scratch with no previous knowledge.
There are a lot of benefits to putting everything in version control:
- The organization is protected in case of a “hit by the bus” scenario or the “lottery” scenario
- In the event of a disaster recovery scenario the application can be rebuilt
- Keeping application and system configurations in version control is highly correlated to increased performance of the team
- By putting everything in version control there is a higher level of automation that can be introduced and utilized.
Contrary to what some development teams think, DropBox is not a suitable version control system. Neither are USB drives, occasional backups to a local machine, relying on developers to always maintain a copy or zipping things up on a daily basis and emailing them to yourself. I’ve seen all of these. (Yes, including the last item.) They are not version control systems. Use Github, Subversion, TFS, virtually anything that supports Source Code Control (SCC) API. Get something real.
Once you’ve got the tool, learn to use the tool. Learn about trunks and branches. Learn when to create a branch and when to merge it back into the trunk. Learn what makes sense to put in version control and what doesn’t make sense.
Version control is such a simple concept, yet using it properly seems to be difficult to many people to understand. Take advantage of the features and make your life so much easier.