Re: A good way to keep documentation for databases as DBA

> On Jun 17, 3:34 pm, Tim X <t..._at_nospam.dev.null> wrote:
>
>
>>
>> Highly recommend using a revision control system. Doesn't really matter
>> which one. I like GIT, but some find it conceptually challenging.
>> Mercurial (Hg) is very similar, but apparently a bit more user friendly.
>> Bazaar (bzr) is also pretty good. Even subversion is better than
>> nothing!
>>
>
> Since I can't get sign-off on any of this from my boss, and indeed,
> can't convince anyone a DBA is necessary, and am working under a RAD
> system where vendor people can get authorization to do all sorts of
> strange stuff without telling me about it, I keep everything on
> subfolders on the server where I can simply search for stuff when I
> need it, and be sure it is backed up, and be sure the rc scripts bring
> everything up right with no attention. If others are too clueless to
> read a script, not my problem (until I have to fix it when I come back
> from vacation). I habitually modify dangerous scripts to start with
> an exit.
>
> I have recently been able to document a couple of problems created
> more than 10 years ago by doing it this way, should you be laughing or
> shaking your head at this.
>

Both! Been there and had this fight. Never understood why anyone would resist using version control. It has next to no additional overheads and gives you so much for so little. When I first started trying to get it adopted where I currently work, I had two problems. One group who were resistant (fear of the unknown I suspect) and another group that wanted to ove engineer its use and came up with an amazingly complicated procedure involving multiple branches, tags and all sorts of process overhead. As a consequence, my first attempt failed.

I left things for a while and then tried again. This time, I insisted on a very light weight, minimal process. This time was successful. After a while, once everyone got use to it and understood it better, we defined slightly more complex procedures surrounding how it is used.

We now have everyone using it. The great thing is, in addition to basic version control, we use it for peer review, have a semi automated 'gatekeeper' process that ensures code doesn't get into the mainline/trunk branch until it has been properly signed-off, have a much more reliable promote process and better bug management. It is even integrated with our issue tracker. Management now wouldn't be without it as they have a much better way to gauge how things are going and our processes are more reliable. Developers now actually like it because it has actually made their life much easier.

My recommendation would be to just start using it. If you use something like git/bazaar/mecurial, there is no sys admin or centralized management required. You can just use it on your own system. At least you can benefit from it. You don't even have to modify your current process that much. All your files, scripts etc will still be laid out as they are now. The difference will be you have a history of changes, logs indicating why, what and when things changed and you can 'push' the whole thing to another system as an easy backup. Many of the latest generation distributed version control systems run on multiple platforms, such as Linux, Windows and Mac.

If your using any Linux systems, there is a nice package called etckeeper, which uses git/bzr/mecurial/darcs to version control all your files under /etc. This utility is hooked intot he package management system, so you don't even notice it there - until you need it. There has been a number of occasions when I've forgotten that a config file was modified for local requirements, have updated its package and allowed the config files to be overwritten by new defaults provided by the package. Rather than having to reconfigure by hand, I can either revert back to the previous version or merge the new and old.

Tim

-- 
tcross (at) rapttech dot com dot au