October 2, 2010 at 1:39 pm
Comments posted to this topic are about the item The One True Script
Best wishes,
Phil Factor
October 4, 2010 at 1:28 am
Unfortunately, not only are we still forced to use one script and one Dev server, but we also have loops to jump through for the DBAs of the Test, Pre-Production and Production servers.
I would love a step by step guide to a perfect implementation strategy, but for now we just keep learning from previous mistakes and trying hard to streamline!
October 4, 2010 at 10:41 am
While I've never quite worked with anything as drastic as the "One True Script" described here, I have seen some pretty odd things, including a software company who's new client installation script for the database created the schema as it was several years ago then proceeded to apply every DDL statement written for the schema since then. Of course this meant it took hours to setup a relatively empty database for a new client.
Somewhere else as a DBA, I had a developer tell me he thought everything in the development database should be recreated from the scripts periodically. So when I asked if he was going to script all the test data that made up the development database to reapply after we reran the DDL and loaded the static/default data, he seemed to quickly drop his push to recreate everything from script. 😉
Where I'm at now, we have several different development databases, esentially one for each project, and then an extra one which is a straight copy of production database for working with current issues and bugs. So they can code at least semi-independently. There is only 1 QA database though, and I wouldn't want to change that. Production shouldn't be the place that interactions between different changes are first seen.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply