Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Goalie35
Yak Posting Veteran
81 Posts |
 Posted - 2012-07-27 : 11:06:48
|
| I'm just looking for some advice on what the best approach is when moving tables, SP's, views, etc from my development server, over to production.Currently, lets say I made updates to 6 SP's and created 4 new ones, as part of some update. When I'm ready to move from development to production, I simply script out my SP's and alter them on production. The other day however, someone needed to make a quick change to a production SP, so they updated production only, not development. So...when I went and made my update, I overwrote his changes.So I was just curious on how you guys handle making updates to development to production to ensure you're not overwriting anyone else's changes. What's the best approach?Thanks |
|
|
nigelrivett
Master Smack Fu Yak Hacker
3385 Posts |
Posted - 2012-07-27 : 11:12:08
|
| Don't you have source control?Have a dev source control systemAlso a production one.The production one shoould have a method of reconciling what;s in production - easiest is to just script the server and compare the result. That will take care of ad hoc changes. I usually run that daily automatically.Release is taking what's checked in in dev and moving it to production.If you use something like TFS things get a lot more interesting.==========================================Cursors are useful if you don't know sql.SSIS can be used in a similar way.Beer is not cold and it isn't fizzy. |
 |
|
|
Transact Charlie
Master Smack Fu Yak Hacker
3451 Posts |
Posted - 2012-07-28 : 13:31:23
|
Every place I've worked has done it differently.Here's the current (skeleton) flow for my company:1) Do development using a development database server (lots of them actually)2) Commit code into svn using the tool of your choice (We use Red Gate Source Control)3) Maintain your code repository somehow (branches / tags whatever )4) Decide you want to take a cut of code to production5) Produce a migration script for that cut (we use Red gate SQL Compare + Source code for this)6) Deploy to UAT testing environment7) Test it8) Deploy to productionThere were a few things from your post that I urge you to think about:quote:
The other day however, someone needed to make a quick change to a production SP, so they updated production only, not development.
Ouch -- doesn't sound very safe at all surely. What if the change had deleted all your data or introduced some pernicious bug or security hole?Do you have any tests for your programmability objects?Transact CharlieMsg 3903.. The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION. http://nosqlsolution.blogspot.co.uk/ |
|
|
|
|
|
|
|
|
How do you handle moving from dev to prod?