Best Practice for synching data in stores?

dchristie

I've got a question for the DevNet community regarding keeping data synched across stores and different boxes, and was wondering if there is a best practice out there doing just that. In our scenario (I hope I can make this clear) we have the need for a Production store, QA store, and a Development store. The Production store is on one Solaris box and the QA and Development are on a separate Solaris box.

Our original plan was to do our development, on the Development store, and then when ready for our QA team we would tar up the store from the Production box, and overwrite the QA store on the development box. We would then use iwmigrate to send our new changes from Development store up to this transferred over store. Once in the QA store, we'd have the QA team do their stuff there. Once approval was there we'd then take the QA store, tar it, and send it back to the production box to overwrite the store there, hence getting our new developments into the Production store.

Ok, so, here's our major hurdle: The data in our Production store will eventually get ahead of the stuff we had brought over into QA earlier, assuming the business will still be inputting work. We do not want to have to bring down Production for the duration of the QA process and subsequent transferring back of stores. But if the business does continue to use Production, we will be out of synch and have new data in that store. So when we write back our store from QA, effectively overwriting the Production Store, we will lose that new data.

So, is anyone out there running a similar configuration that might have better solutions to having a Production, QA, and Development stores and keeping them synched up? I hope that description wasn’t too bad; We’re just trying to develop some best practices for when we need to send our development on to the other stores. Any ideas would be great.

Frederik

I'm thinking this is one of the basic issues in release management for Teamsite based projects, so you may find stuff by searching devnet. Although I can't really think of a specific (recent) thread.

What we're doing
(1) work in DEV, and prepare an "install procedure" (partly scripted, partly manual) to upgrade the project.
(2) we copy the relevant PROD _branch(es)_ (not store) to the QA server (we're using a homemade script using tar + iwextattr for the Extended Attributes, but iwmigrate should do equally well).
(3) we run the install procedure on QA
(4) QA testing, and possible modifs to install procedure back in DEV + update to QA
(5) we run the install procedure on PROD

The risk is of course that if changes in step 4 are too extensive, our step (5) is more than just a repeat of step (3). Meaning that we may have messed up the procedure if we weren't careful. If in doubt, repeat from step (2), but even then, you only get your backing store back in pre-upgrade condition; but with that you don't get the rest of your server / TS config back to pre-upgrade condition.

The fact is that if you have multiple projects on your TS box, you'll risk to de-synch more than just the project that is getting a new release, with the process you proposed.

Further, you have to analyse in detail what will be the effect of your changes in the DCT/TPL to the data you're having. So far, we've done only minor upgrades to our projects, so I can't really tell if our approach will hold for a major overhaul.

I hope to see other opinions...

-- Fred