Wednesday, September 26, 2007

The thing we want Softgrid to do (Active Upgrade+)

This entry started as a comment on

The thing with Active Upgrade is that (as the article points out), the user gets the update automatically on next launch of the application. This is a major step forward for application updates. However, it does not solve the whole application testing problem: before pushing changes to the users, I need to test the application. In order to test, both version need to coexist but with Softgrid it is not X and Y but X or Y. The fact that a rollback to an earlier version of an active upgrade is not possible adds to the complexity.

What I basically want is:
1) Make a parallel application branch Y (as it is called in the article) from version X
2) Test this branch (without impacting the existing version)
3) Update the parallel application branch if required (using active upgrade)
4) When tests are successful, use Active Upgrade to update the production version X

This scenario is inherently not feasible because in stage 1, a new asset directory and a new GUID is created so that settings are stored in a different location.

The scenario that comes closest to what I want is the following:
1) Make a parallel application branch Y
2) Test this branch
3) When tests are successful, apply exactly the same procedure to the original version X, but this time using active upgrade.

The main issue in this case is the fact that you need to record the exact upgrade scenario in order to apply it again in step 3.

An other workaround exists, though:
1) Make an active upgrade
2) Test this update by manually importing the SFT file on the client (instead of streaming it)
3) When successful, do the update centrally with active upgrade.

I hear you thinking: but we have a Test envionment in order to do application tests. Ok, right, do you have a test copy for every production database to name just one example of why production tests may be required.

No comments:

Custom Search