in reply to OT: Ways of managing changes to a database's structure during a project.
We used option 2. Options 1 and 3 just take too long, and require the database to be unavailable while modifying it. Now, this is ok if apply patches to your production environment every three months - you do that in a sceduled window anyway. But in a testing environment, you can't make your testing databases unavailable for half an hour three times a day - and have 30 or 40 people unable to do their job. You want to be able to make updates on the fly.
The boundary between development and staging was a bit different. The same database modification scripts were used, and there where two staging databases, db1 and db2, both identical, and with minimal data. If a developer wanted to 'release' one or more scripts, the scripts were first applied to db1. If no errors or warnings occurred, the scripts were applied to db2 as well. However, if there was a problem applying the scripts to db1, the scripts were rejected, and a copy of db2 was loaded into db1.
Furthermore, before scripts could be taking out of staging, and into testing, I had to sign them off. Without my approval, they wouldn't make it into testing (let alone be released).
Anyway, that was far more than I wanted to write.
Abigail
|
---|