By now, most folks – in both development and operations – should understand the benefits of source control, but if not, here’s a brief recap of some of the benefits of using source control:
- History of revisions – assuming you update and commit regularly, you can easily rollback changes if needed and narrow down the points in time when a certain change was made
- Recover from accidental deletions – if you delete a file (or directory) you can easily recover the last version you committed to source control
- Enable parallel work on the same files – with most source control systems multiple people can easily make changes to the same file(s) in parallel and merge changes as necessary
- Build upon source control with your build system and/or continuous integration system to be able to trace all deployed versions of applications back to the individual changes that went into a given version.
And so on and so forth. However, the one key assumption about all of these benefits is that you placed your file(s) into source control in the first place! The easiest way to avoid missing out on these benefits and to avoid problems caused by bypassing source control is to adopt the simple mantra: if it’s not in source control, it doesn’t exist!
Think about an all too common scenario: you start working on creating some new custom tool. Let’s say it’s some awesome PowerShell script you dreamed up. You tinker with it on your local machine for awhile. Things start to look good, the script produces the results you expected in a test environment so you decide to conduct a field test. You copy the script to some random production server, schedule it to run nightly for a few days just to get a feel for it. The script works great. Maybe it produces some sort of email output that you think would be useful for other members of your organization, so you configure it to email others as well. People love it! Job well done! So you leave the copy running on the production server and meanwhile begin making changes to your local copy for the script’s next awesome release.
Then one day, catastrophe strikes: one of your colleagues needs to re-purpose that server from which you run your script. Innocently enough they forget to check the Scheduled Tasks and as far as they can tell the server is unused, so they wipe it out and begin rebuilding it. Oh noes! Your script is gone! And your local copy is in a half-working state that can’t be released. So now that script that was happily running in production no longer exists. People start complaining about why they aren’t receiving that awesome email output anymore and the investigation begins. So who’s fault was it?
IT’S YOUR FAULT.
Whenever you begin working on a new script or source file or pretty much anything that will exist in production there should always be two steps:
- Create the new empty file
- Add it to source control (and commit it!)
Granted the person wiping out the server should have checked the Scheduled Tasks for existing processes in this example. However, your failure to add your script to source control in the first place, and somehow tag or label it accordingly (so you could reproduce the production version from source control) is what made a bad situation worse. Your negligence has now completely ruined the reproducibility and accountability of the state of your production environment.
Anything and everything that exists in production, from application binaries, to administrative and utility scripts must be placed into source control and only released from source control. Ultimately, releases must happen from a pristine checkout/working copy/export of the revision to be released, not from some local workstation copy.
Any change to production, no matter how trivial, must come from your system of record – a.k.a. the single source of truth – your source control system. Adding resources to source control immediately is a simple habit you can apply to your own personal workflow to save yourself from headaches in the future and help ensure accountability and maintainability of your production application assets. If it’s not in source control, it doesn’t exist!
