We need a back out plan for a web app whose first maintenance release is going to production soon. The issue we are facing is even if we back out new EAR and deploy old one , the data which was keyed in using new release would not support old business rules(current), since there is enormous changes in business rules. Can you suggest how do we tackle this issue?
+1
A:
This generally requires a systemic approach that places constraints on how you evolve the app. For instance, it's better to roll out schema changes first and have them sitting benignly in the old app. Then, if possible, roll out the new system in parallel with the old, and hit it using test accounts. Finally, you roll out to customers, ideally in a staggered approach.
Without knowing the specifics of your app, I can't say how viable this approach is for you, but I will say that it usually requires a lot of thought at the early stages of design for a new release.
Marcelo Cantos
2010-03-27 10:36:28
There are no schema changes in new release. The only change is boundary conditions of some business rules. For example term value of a product allowed in earlier release was 6 yrs and its 9 yrs now. If a user selects 8 yrs as term value after new release going into production and if we back out the changes, the data keyed in would fire old version of app. We have a pre-prod environment where system is being tested. But customer wishes to have a back out plan for being on safer side.
nobody
2010-03-27 10:45:28
+1
A:
That's a VERY difficult question to answer without prior knowledge of the system. Would there be an upgrade path for the old data to work correctly with the new release? If so you probably don't need to worry. You might have something like the following scenarios:
- The new release is so bad it cannot be used and has to be rolled back - no new data worth speaking of will be entered, just restore old version with old data
- New release is OK, some problems with it, you'll need to temporary roll back - new data will not be available, you could manually adjust some of it if absolutely necessary, meanwhile your team works like mad on fixing new release and re-deploying
- New release is fine, server crashes - you just restore from the backup you've made after the installation with all the new data converted to use new rules
Ilya Kochetov
2010-03-27 10:41:27
okay. To make things clear, let me tell a scenario. As per old app the maximum age of the customer allowed for a product is say, 35 and as per new business rules its 40. Suppose a customer did a transaction with age as 39 which is not supported by old rules. So if customer does any maintenance on his account/transaction, the system would fatal. Also in this case we cant modify the age of customer to support old version of app.
nobody
2010-03-27 10:51:26
instead of fatal the system could simply mark the bad data so that somebody (human or not) can handle it before its processing resumes
mjustin
2010-03-27 15:45:49
@nobody: can you please give an example of the scenario when an old version of the app is used on the new data?
Ilya Kochetov
2010-03-28 17:50:05