1.Downtime can be eliminated almost completely, even planned downtime.
2.Major changes are stressful to end users, and there is a high risk of an associated loss of productivity. Think Windows Vista and Windows 8.
3.Rollbacks are usually more complicated than updates. If updates are big, the risk of problems increase, and rollbacks can become very painful. Avoiding a single rollback is usually worth a few extra updates.
A customer that needs (or wants) to influence the development of FastTrak should have these implemented:
1.A separate AD group with pilot users, receiving the new product version first in a gradual rollout.
2.A separate executable for the (new) piloted product version, named FastTrak_Pilot.exe. This executable is the Rollout Candidate (RC).
3.A separate startup shortcut distributed to the AD group mentioned above, pointing to the RC.
4.An automated process that restores the latest backup of the production database to a test database, e.g. a backup of EFT00028 is restored to EFT00028_TEST every night.
The test database is not used by the end users, but by the vendor to test an RC before piloting. It should always be de-identified. There are specialized tools available for this purpose.
This is the recommended change process for FastTrak installations.
1.The vendor tests database upgrades in the test database, using a copy of the application version that is currently in production.
2.A request for change (RFC) is sent when the planned database upgrades are found to be good. This is usually LOW risk, but may be MODERATE og HIGH, depending on the circumstances.
3.After approval, the vendor or local IT staff performs database updates outside normal working hours. This may or may not require downtime, depending on the extent of the upgrade and the risk level. Usually, no downtime is needed. Moderate and high risk updates should be done with all users logged out, to avoid data loss in the event of a rollback.
4.The next rollout candidate (RC) of the application (if one is ready) is installed by the vendor (see "Infrastructure").
5.The selected group of users evaluate the RC for 2 weeks, and give a go or no-go decision. If the decision is no-go, make a new RC with necessary fixes and move back to #4. For a GO decision, move to the next step.
6.An RFC is sent to ask for replacement of the current application version with the RC. This will be usually LOW risk, given that the steps above have been completed.
7.After approval, the vendor or local IT staff replaces the executable outside normal working hours.
The rollback from #7 is to simply replace the executable file with the previous version. The only potential high risk change (not easy to revert) is in step #3.