Re: Opinion on change control for DBA scripts
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: Andrew Kerber <andrew.kerber@xxxxxxxxx>
- Date: Wed, 26 Jun 2013 15:08:10 -0500
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@xxxxxxxxx>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.
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
