Change ManagementMay 1st, 2007 — ddelmoli
I know, I’m staring at a box with the word Pandora written all over it.
Over the years, I’ve worked on many ways to let database schema evolution and software change management co-exist peacefully.
During the early years, I was happy if the init.ora file was under SCCS control. I re-read the original OFA document and couldn’t find any reference to pfile standards, but I recall that we thought it would be neat if changes to the init.ora file were tracked and kept under version control with history.
James Morle has an excellent section in his book, Scaling Oracle8i, which discusses the init.ora file and mentions SCCS here.
This is one of the reasons I don’t use binary spfiles nowadays….
Anyway, back then we didn’t worry so much about schema evolution and change management. Who would’ve thought that these systems would last long enough to have such a requirement?
I was introduced more formally to database source code control by John Beresniewicz, whom I met during my time as CTO at Savant Corporation. John was the primary developer of an application (Savant Q) which had a repository and several robust PL/SQL packages. It was one of the first retail applications I encountered which made heavy use of PL/SQL. As such, John had everything under source code control using MS SourceSafe. Since the company was really small, I ended up chipping in on the installation code.
As with many retail applications, the focus of the installation code was on “clean” installations instead of upgrades. So, our source code control reflected that with heavy control on the creation commands, and specialized files for delta upgrades. Packaging usually meant making an image of the entire source tree for burning to CDs.
Source code control for packaged software differs somewhat significantly from that for custom internal corporate applications. Heck, source code control at many corporations can be a hit-and-miss affair for all kinds of code, let alone database schema evolution.
My current company has a very strong source code control ethic, which has led me to work on ways to manage schema evolution in line with that sense of responsibility.
The goals differ somewhat from the ones we used on packaged software. “Releases” occur very frequently, often every 2 months. The emphasis is on “upgrades”, not installations from scratch. (Every once in a while, I get asked about whether or not we could create the corporate databases using only the scripts from source code control. While I’d like to support that, the real need for such a capability is low. The idea that I’d take 5-7 year old scripts to create an empty database and re-import 2-3 TB of data seems silly to me when it would be much, much more practical to practice doing backups and restorations).
I intended this topic to be the subject of my paper at Hotsos 2007, but I ended up not being able to attend the conference, and with that the paper never got written.
2 recent blog posts *here and here) by Dominic Brooks got me to thinking about this topic again, so I’ll be posting on it over the next few days. Perhaps with your feedback, I’ll eventually coalesce these posts into a decent paper on the subject.