[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sdd] [requirements] use case for 2.1.6.1: sidegrade (side install)
Question inline... > -----Original Message----- > From: James Falkner [mailto:james.falkner@sun.com] > Sent: Wednesday, February 22, 2006 6:03 PM > To: sdd@lists.oasis-open.org > Subject: [sdd] [requirements] use case for 2.1.6.1: sidegrade > (side install) > > Specific problems of supporting in-place upgrades: > > By only supporting in-place upgrades, ISVs must deliver > complex solutions to enable customers to enable customers to > update/upgrade in place without having to force customers to > allocation additional systems for update/upgrade purposes. > The matrix of version combinations required to be tested and > supported can quickly become extremely complex. It is costly > for ISVs to be able to certify that many of these > combinations of component versions will work properly. The > pervasive support results in complex and error prone > technical solutions which often result in corrupted in-place > installations, forcing a removal/reinstall. > > Specific use case of sidegrade: > > Customer is running particular customized version of > software, including custom data that was created after the > initial install, and custom configuration tuned for their > environment. This is running either in a production > environment or development environment, with high > availability requirements (i.e. can't be taken down except > during scheduled maintenance periods). [John Patton] Would this not be met with requirement 2.4? The user can decide if they want to install the new version in a sidegrade fashion by installing it as a second instance? > Customer obtains latest version of software, and would like > to upgrade to that version, with the ability to revert to the > old version if the new version does not operate as expected. > > Customer installs the new version in a sandbox-type environment (i.e. > different directories/folders, different port numbers, etc) > and must now migrate user data and configuration from old to > new version. Customer then tests that the new version works > as expected, in this sandbox environment. If it does not, > the current version continues to operate. > If it does, customer selects a convenient time to switch to > the new version, by disabling the old version, changing the > new version to use the standard external port numbers or > other end user interfaces, and finally uninstalls the old > version. This is a sidegrade. > > Basically, supporting sidegrades are to 1) reduce the testing > burden by only requiring testing of the migration tools, 2) > support revert when things go wrong, and 3) minimize downtime. > > -jhf- > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]