Chris's Wiki :: blog/sysadmin/VersionControlFirst Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/VersionControlFirst?atomcommentsDWiki2012-12-30T15:34:08ZRecent comments in Chris's Wiki :: blog/sysadmin/VersionControlFirst.From 99.237.23.137 on /blog/sysadmin/VersionControlFirsttag:CSpace:blog/sysadmin/VersionControlFirst:02c8309c31e000c50943ef11849fdc540bed0a5cFrom 99.237.23.137<div class="wikitext"><p>Prior to working at my last job (which I started in 2003) I'd never used any form of version control on my systems beyond the typical "cp rc.conf bak-rc.conf" type strategy. At the last job, the grandboss was absolutely fanatical about RCSing everything. Now I can't imagine why anybody would want to do it any other way. Your changes are right there, on the system, no web browser or editor or svn/git/hg magic required. True, they're not off-system in case of a catastrophic crash, but that's what backups are for, right?</p>
<p>I agree that living documentation can be nice too, but unless you're the only person working on the system, and you're as fanatical about updating that doc as my former grandboss was about RCS, it will at some point be out of date. If you're not the only person working on the system, the context is gone until somebody notices it's missing and then figures out who was responsible for the change. Hopefully that person remembers why they made the change they did.</p>
<p>-- Mike</p>
</div>2012-12-30T15:34:08ZFrom 89.70.184.230 on /blog/sysadmin/VersionControlFirsttag:CSpace:blog/sysadmin/VersionControlFirst:4c7f04881b327e3cbaf4e5504085ba4b70daea56From 89.70.184.230<div class="wikitext"><p>I agree with Chris. I have invented the very same strategy on my own, to keep config files in a VCS (git, to be specific) -- it was a Postfix server for 300+ users and I didn't have a luxury of having real test environment, changes needed to be applied on a living thing.</p>
<p>As a sysadmin I can tell that there are very little things to be changed with editor that don't fit into VCS. Of course, there are things that are changed using different methods (Zenoss' or Zabbix' configuration, for what I hate them and appreciate Nagios), but those are rather rare in un*x environment.</p>
<p>-- <br>
dozzie</p>
</div>2012-12-22T20:28:38ZBy Chris Siebenmann on /blog/sysadmin/VersionControlFirsttag:CSpace:blog/sysadmin/VersionControlFirst:a236f21187461b1a7d4dd43526761cb0dfeacb11Chris Siebenmann<div class="wikitext"><p>Version control isn't just for scripts and code. It's for any
configuration file or control file and in fact any text file that isn't
automatically generated and doesn't change so often (by automated
or uncontrolled means) that you can't feasibly check it in. We
version control code, scripts, the list of our local networks, Apache
configurations, DNS zone files, DHCP configurations, VPN passwords
(automatically, through a script), and even our master <code>/etc/group</code>.</p>
<p>If you literally have nothing you can version control, well, then I
suppose that you can't introduce version control. But this is not the
same thing as version control not being the right first step. <em>If you
can version control things, you should</em>. As the first step.</p>
</div>2012-12-21T22:58:15ZFrom 69.164.167.126 on /blog/sysadmin/VersionControlFirsttag:CSpace:blog/sysadmin/VersionControlFirst:caa4e251bd09711206c36dce5044013b25511b5cFrom 69.164.167.126<div class="wikitext"><p>I suppose this really depends on what we are including in the definition of duties under “Sysadmins” If one’s role is tweaking scripts all day, then cool, spin up a repo in a subversion server or something. Absolutely a must. Trust me, I currently administer a Software Development environment, so I do completely understand how important it really is. But if you are provisioning a brand new system or collection of systems that serve a role, or introducing anything (especially hardware based) that is doesn’t easily fall into a version control mechanism, then there is a gap. IT deals with different ingredients than Software Dev does (hardware, and systems, OSs, apps, etc) that do not lend well to a true version control model. I’ll love the day when the industry is at the point in which everything can fall under revision control, but its not even close to being there yet. I think that we would both agree that at the end of the day, its about understanding what has changed. If that is the essence of the topic of discussion, that I find it difficult to be able to rationalize how “documentation is nice but not crucial” when version control is, especially when we’ve already identified the inherent gaps that come from a lack of being able to apply a version control mechanism to every task that is performed in IT.</p>
</div>2012-12-21T18:20:23Z