January 20, 2010 at 6:34 am
We keep change scripts for tables, and generate alter scripts for sproc, etc. and we do this pretty religiously. My question is, in an effort to make deployment to prod quick (since we need to do the deployment in the wee hours on Sundays) we're debating whether to combine as many scripts as possible, like one big script for all sprocs, one big script for all table change, one big scripts for data. That or just keep each script separate and just take the time to run them individually. And of course maybe some half-way approach where some are combined, some not. In any given run we might have 100+ change scripts.
What's a typical approach?
January 20, 2010 at 8:06 am
My preference is to keep the scripts separate and run them one at a time. In our environment, we release bug fixes and enhancements to beta as they're fixed and to production once a month. For this reason I like to keep the scripts separate so I know that the exact script that was released to beta is the same one being released to prod.
_____________________________________________________________________
- Nate
January 20, 2010 at 9:33 am
We use Redgate's SQL Compare.
You can generate a script for all the changes - eg from UAT to Live.
You can also run the same compare to get a script from Live to UAT before the release - you can then use this as a rollback script.
I use the same process from Test to UAT so I normally have a good idea what the script will look like.
Seth
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply