Re: Opinion on change control for DBA scripts
From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Wed, 26 Jun 2013 16:10:04 -0500
Message-ID: <CA+fnDAbOJQ=9gYikwRix1z7DGXEQgh+x9NcjjRhdYvUdhyzCtg_at_mail.gmail.com>
to your point and also Mark's, control of centralized source control systems is a big issue in every org. not just a reason for DBA groups avoiding existing sccs - but even within an organization it's the reason for the big debate of one centralized sccs vs several sccs for various groups in the org. in the broader software engineering field (and especially the open source world) it has led to the development of distributed models for sccs and the ensuing bug debate of whether centralized or distributed sccs is better. there are pros and cons. it's the reason i setup a new SVN repo just for my DBA group instead of using an existing SVN repo in our organization.
if you want an easy way to just track history, you might check out git. it follows the distributed model, doesn't use a central server anywhere - so you don't have to set anything up. it just uses a few hidden directories to store info. basically you can use it to bolt-on history to your script directory. you can backup the directory like normal.
Date: Wed, 26 Jun 2013 16:10:04 -0500
Message-ID: <CA+fnDAbOJQ=9gYikwRix1z7DGXEQgh+x9NcjjRhdYvUdhyzCtg_at_mail.gmail.com>
to your point and also Mark's, control of centralized source control systems is a big issue in every org. not just a reason for DBA groups avoiding existing sccs - but even within an organization it's the reason for the big debate of one centralized sccs vs several sccs for various groups in the org. in the broader software engineering field (and especially the open source world) it has led to the development of distributed models for sccs and the ensuing bug debate of whether centralized or distributed sccs is better. there are pros and cons. it's the reason i setup a new SVN repo just for my DBA group instead of using an existing SVN repo in our organization.
if you want an easy way to just track history, you might check out git. it follows the distributed model, doesn't use a central server anywhere - so you don't have to set anything up. it just uses a few hidden directories to store info. basically you can use it to bolt-on history to your script directory. you can backup the directory like normal.
careful of github or dropbox if your scripts have anything proprietary in them (db names, IPs, paths, etc). i know there's encryption and other safeties, just be prudent with where you let your data go. not a bad idea to just keep your scripts inside the corp network...
-- http://about.me/jeremy_schneider On Wed, Jun 26, 2013 at 3:40 PM, Sandra Becker <sbecker6925_at_gmail.com>wrote:Received on Wed Jun 26 2013 - 23:10:04 CEST
> 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-l