<< Click to Display Table of Contents >> Navigation:  Technical documentation > Change process

Background

A structured change processes should be designed to reduce risk, but also to reduce the cost of change.  The change process for FastTrak has been designed to avoid downtime.  A major element is to keep updates frequent and small.

 

Small incremental updates are preferred for these reasons:

 

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.

 

Rolling back the database and the application at the same time will be more complicated than rolling back just one of them.  Updates to database and applicaton are decoupled in our change process.  This makes it easier to determine whether a given problem is caused by a database change or an application change.

 

Infrastructure

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.

 

Overview of the change process

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.

 

Downtime

During database upgrades (#3 above), downtime is usually not needed.  During program updates (#7), downtime can be avoided by renaming the old executable and using the standard name (FastTrak.exe) for the new executable.  As a general rule, updates can be done with zero downtime by following this process.