June 22, 2007 at 1:09 am
It's amazing what people come up with as a "change management" process but I've never encountered that kind of madness before...did someone mention ITIL training? I think it's just basic common sense...
If you're interested in a proper process for managing SQL Server changes then take a look at DB Ghost http://www.dbghost.com.
It's being doing for 5 years what Microsoft have only just started doing with Visual Studio Team Edition for Database Professionals (and they charge 10 times the price!).
The main idea is that all your SQL code should be in CREATE scripts under source control so that it can be fully audited and then released in an easy, reliable and coherent way. Basically it means you can regard the set of CREATE scripts as your "source database".
Malcolm
DB Ghost - Build, compare and synchronize from source control = Database Change Management for SQL Server
www.dbghost.com
June 24, 2007 at 9:05 pm
Thanks for the replies Brandie & lindss01. For all our environments, except the one mentioned, we use both of your procedures combined. Development, testing, UAT and finally production. Nothing gets to testing, UAT or production without release scripts and change controls. Works well.
ITIL, commonsense, I'm sure some people have never heard of either!
June 24, 2007 at 11:33 pm
Step 1. Nominate the current DBA for a "Darwin Award".
Step 2. Fire the current DBA.
Step 3. Promote the developer to DBA with the caveat that if he doesn't impliment the correct code promotion safeguards, that he will also be fired the very first time he does it wrong.
And, yes, the idea of anyone promoting code without at least a unit test and a "second party" test, is dead wrong. Here's our process...
Note that we also write datacleanup scripts so they are NOT self committing. The DBA examines the expected rowcounts (well proven by then) and compares to the actual rowcounts. Depending on the type of cleanup, if the rowcounts aren't either spot on (ie. configuration changes) or within a certain tolerance (ie. changes to all customers or groups of customers), the DBA immediately rolls back the code and all associated code.
At NO time, is anyone allowed to promote code directly. Except for key maintenance developers, no "normal" developers have write privs on the production database and, since the dev environment is updated from production on a regular basis, many of them don't have read privs on production.
It took us a long time to get to a "no faults promoted" scenario using the methods outlined above, but it has been worth every bloody minute. It takes a lot longer to find and fix a problem in production than it takes to slow down a bit and use the steps outlined above.
Now, if I can just get the Java boys to follow the same rules
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply