Re: Opinion on change control for DBA scripts
From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Wed, 26 Jun 2013 15:08:10 -0500
Message-ID: <CA+fnDAbhbYpdx7KQf=hRZ8GNHhsd+8Yb6wY7V8f1xcd3jvXiYA_at_mail.gmail.com>
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.
Date: Wed, 26 Jun 2013 15:08:10 -0500
Message-ID: <CA+fnDAbhbYpdx7KQf=hRZ8GNHhsd+8Yb6wY7V8f1xcd3jvXiYA_at_mail.gmail.com>
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:Received on Wed Jun 26 2013 - 22:08:10 CEST
> 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.
>
>
-- http://www.freelists.org/webpage/oracle-l