Options
Restore metadata after server image?
k8r
Posts: 2
A customer's environment is setup like this:
This refresh approach makes sense because of the limited bandwidth between the two networks and the amount of data that's included in the refresh. Also, databases are often removed and added in their multi-tenant model, so all databases are included in every refresh automatically without the need to add inclusions/exclusions to a custom built utility.
I'm looking for suggestions for how to either work with this refresh process or change the refresh process so that source control history is not lost.
Current ideas:
1.) Save off the RedGate Source Control metadata before the new Development server spins up. Then re-apply it once ready.
or
2.) Preserve the original Development server (A). Replicate Production to an additional Development server (B). Refresh just the data from Dev server B to Dev server A.
The customer also has concerns about preserving the functionality of SQLDiff, and is also approaching all of this with the intent to also begin using a fully automated SQL deployment tool. These are lower priority for me, because I think there are multiple concerns to tackle here. Preserving source control history is probably the best start.
- Two networked environments - Production and Development - that are each completely separate and firewalled.
- The Development SQL server is where the shared RedGate Source Control lives.
- The customer's SQL Production-Development refresh process involves taking an image of a Production SQL server and spinning it up on Development to replace the current Development SQL server. The Development SQL Server therefore "loses" all of the source control history.
This refresh approach makes sense because of the limited bandwidth between the two networks and the amount of data that's included in the refresh. Also, databases are often removed and added in their multi-tenant model, so all databases are included in every refresh automatically without the need to add inclusions/exclusions to a custom built utility.
I'm looking for suggestions for how to either work with this refresh process or change the refresh process so that source control history is not lost.
Current ideas:
1.) Save off the RedGate Source Control metadata before the new Development server spins up. Then re-apply it once ready.
or
2.) Preserve the original Development server (A). Replicate Production to an additional Development server (B). Refresh just the data from Dev server B to Dev server A.
The customer also has concerns about preserving the functionality of SQLDiff, and is also approaching all of this with the intent to also begin using a fully automated SQL deployment tool. These are lower priority for me, because I think there are multiple concerns to tackle here. Preserving source control history is probably the best start.
Comments
For preserving the metadata the best way I can think of would be to create a separate DB for logging changes and moving that over as well when you do the image restore, along with any relevant configuration files. There isn't really a way built into SQL Source Control for this use case so there will be some charting of unknown waters on this type of environment but it should be doable to move the data over.
http://documentation.red-gate.com/displ ... by+Unknown
http://documentation.red-gate.com/displ ... +databases
Red Gate Software
US Product Support