Re: Opinion on change control for DBA scripts
Date: Wed, 26 Jun 2013 14:40:27 -0600
Message-ID: <CAJzM94DYHJWxDbHjmPjP+ODY4yG8LmiGJOH6vP6TfqquM1LeXQ_at_mail.gmail.com>
Jeremy,
You bring up some good points I hadn't considered before. As the only DBA at the company, I don't have to worry about other people changing my scripts and I always make a copy before I do any edits. Something I learned to do 20 years ago when I first became a DBA. None of the scripts I lost were critical to the operation of the company, only to me as the DBA. They use svn for the application code. I don't have access to svn though. In the past I've been told it was only for application code, not the silly little scripts a DBA would write. Development handles all the control of svn.
In 7 years here the only issue with my scripts was IT not backing up my script directories on the database servers. In fact, they didn't backup anything on my database servers. (My DB backups get written to disk on another server so they're safe. And yes, I have tested restores from the backups.) Their thinking was that I could always copy what I needed from another database server because all databases are the same. Right. And pigs fly too.
Shortly after the second time IT wiped out my scripts (tracked it down to them doing some disk cleanup), they were told not to touch anything on database servers without checking with me first and to start backing up every directory I designated immediately. I even tested to see if they could restore a file for me and it was successful. However, they recently fired the only sys admin who really knew how to retrieve anything from tape. Hmmm... I copy all my scripts to a thumb drive on a regular basis--lack of trust issue on my part. Once bitten, twice shy; twice bitten thrice shy.
Sandy
On Wed, Jun 26, 2013 at 2:08 PM, Jeremy Schneider < jeremy.schneider_at_ardentperf.com> wrote:
> When I started at the company where I now work, DBA scripts were copied
> everywhere and would be updated on the fly. One guy was kindof the main
> owner and would generally keep stuff merged and in his head he usually knew
> which server(s) had the latest copy of some particular script. But
> sometimes it took some looking around. This has generally worked fine in
> the past, but now we're in a fairly rapid growth phase and I decided it was
> time to improve our processes in this area. I started a conversation that
> included architecture, dev, and ops in addition to our engineering group...
> selected svn as the most appropriate system (based on history and existing
> systems and skills and roadmaps within the company) and setup a repository
> for our group - now all scripts are in change control and I am much happier
> with the many benefits of this. I know where the "authoritative" copy is,
> I can view history showing who changed which lines if something stops
> working and I can revert changes, and it provided a foundation for
> automatic deployment and continual updating on all servers.
>
> It's a favorite issue for me personally, I feel somewhat strongly that
> most DBAs are doing software engineering with the thousands of code they
> maintain in scripts yet completely ignoring the entire field and deep
> knowledge that's available. Not that you always need to use a heavy-weight
> change control system or SDLC process. But treat that stuff like the
> *code* that it is, and ask the same set of questions that any decent
> software engineering shop would ask about the appropriate way to treat your
> particular code base. The most important question isn't "do you check your
> script in" but rather the most important questions are higher-level... what
> situations do you need to be protected from and how is that done.
> (backups? history? central authority? traceability?) A shared script
> library that multiple people maintain has different requirements than a
> personal script library. Scripts that you want to share with the community
> have different requirements than scripts which must remain proprietary and
> confidential. Scripts used occasionally by one person have different
> requirements than scripts maintained by the engineering team and used
> heavily by another operations team. Some scripts are called by other
> scripts or processes - and these may need well-defined interfaces and
> maintain compatible behavior across updates. Your scripts might be copied
> to two servers or they might be copied to two thousand. Everything depends
> on your particular case.
>
> Just a few thoughts...
>
> -J
>
>
> --
> http://about.me/jeremy_schneider
>
>
> On Wed, Jun 26, 2013 at 2:41 PM, Andrew Kerber <andrew.kerber_at_gmail.com>wrote:
>
>> I keep copies of everything, but I have occasionally had to do formal
>> change control (ie, keep a source library, comment all changes, move
>> through test/dev/prod process) on some scripts. Basically I always just
>> copied whatever development was using I had to. But disk space usage
>> records is not a dba job, its a systems job.
>>
>>
-- Sandy Transzap, Inc. -- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 26 2013 - 22:40:27 CEST