May 26, 2011 at 5:53 am
We have some systems that require thorough testing before any code changes go live. I have now been tasked with keeping DEV up to date (many many hundreds of tables) with LIVE data to make this testing accurate. However - the stored procs etc are obviously a work in progress on DEV so not the same as on LIVE. Therefore I cannot just restore backups over the top.
What strategies to any of you use in your environments? I know this is quite a common scenario. we haven't really had to have the dev and test environments up to date data wise until some recent projects.
Any ideas would be great (as at the moment I'm just getting the BCP/SSIS targetting specific tables and taking a shedload of time to put in place initially)
May 26, 2011 at 6:05 am
you ideally should have a Third enviroment for Test/Pre-Production to do the testing rather than on Dev.
But I find the best/easiest way to keep my test environment in Synch is to use SQL (Data) compare from red-gate.
May 26, 2011 at 6:09 am
Just wanted to know the recovery model of your database.
May 26, 2011 at 6:17 am
asteszt as ats
May 26, 2011 at 6:36 am
I'm in agreement with Steve, a proper environment should have at least three escalation points e.g. Development, Test/UAT and Production.
Usually Test/UAT and Production are the same size; Development can be a scaled down version in terms of size.
Keeping Test/UAT up-to-date requires two things:
1- A refresh protocol
2- A change control system.
Refresh protocol tells you when to refresh.
Change control system tells you which DDL and Code has to be reapplied to Test/UAT after basic refresh.
This is a four steps process...
1- Basic refresh... restore production backup as Test/UAT
2- Credentials... disable Production users that should have no access to Test/UAT and, create all Test/UAT only users.
3- DDL and Code... reapply all DDL and Code expected to "survive" refresh process,, see Change Control System.
4- Privacy... alter confidential data like CC#, SS#, etc so not to create a privacy hot spot.
Hope this helps.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.May 26, 2011 at 7:17 am
Good strategy PaulB thanks. That'll be a good starting point.
Of course I agree with the environment suggestion and we do have the 3 steps setup (dev/user test/live) but im referring to DEV as our starting point for this plan. Normally Dev would be cut back but this current development requires a whole host of lookup and rules tables to be populated for the development work to even pass initially QA/Proof of concept.
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply