Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

how to migrate changes to production server Expand / Collapse
Author
Message
Posted Sunday, November 8, 2009 6:59 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, September 29, 2010 5:23 AM
Points: 194, Visits: 2,357
In addition to the advice from Eliott W and robert.mcleod, I would also recommend that you have a QA version of the database that mirrors live. First test all your scripts for the migration against that. Then have a number of users test all apps which access the database and SIGN OFF the tests - or highlight weaknesses or failures against the testing schedule.
If you do not have a formal testing and signoff process agreed by management, which they know can be traced back to them in the event of issues arising, you are - in my experience - going to get no worthwhile effort from a significant proportion of the user base. <waves hand in airy fashon> yeah, yeah. Whatever, I'm busy you know. User may actually bother trying to log in ... if you're lucky.
Amend your scripts AND DOCUMENTATION to take into account any issues arising from the qa - then restore and do EVERYTHING again. Once you have full signoff - then you can use the exact process you have set up, and documented, to do the move to live.
While this process is undertaken, there should be a code freeze on both the database and the apps accessing it. If the freeze has to be broken - eg to fix a critical bug, then it's back to the start with qa, etc to ensure the changes work with the updated functionality.
You should also have tested your rollback in a qa enviromnent so if you get a user who has signed off, but not done thier testing job effectively - or indeed if you make an error in your process - whatever, and something critical breaks, your way back has also been tested appropriately.
Post #815549
Posted Thursday, November 12, 2009 8:05 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, May 21, 2012 3:13 PM
Points: 516, Visits: 1,563
I like to use Red Gates Sql-Compare to generate a script that will synchronize the test and production databases. I then use the script as a starting point for a script to make the changes to production. This helps me to not miss anything.

Steve



Post #817860
Posted Friday, November 13, 2009 8:21 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: 2 days ago @ 6:26 AM
Points: 1,182, Visits: 1,971
First off, you should be using a Source Code Control system.

Then you need to create an "Upgrade Schema" script that can be run in batch mode against your QA databases first and then, after all testing has been done, against your production database(s).

Watch out for automated tools that perform comparisons between two databases. They will not get it right or will only handle the "simple" changes. See: http://www.sqlservercentral.com/Forums/FindPost702354.aspx which describes a schema change that involved XML binding.

See the following post which describes our process.
http://www.sqlservercentral.com/Forums/FindPost474053.aspx You may wish to read the entire thread as a lot of the "experts" provided some good advice to this exact problem.



(PHB) I think we should build an SQL database. (Dilbert) What color do you want that database? (PHB) I think mauve has the most RAM.
Post #818541
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse