The primary reason behind all the risks associated with parallel development is poor configuration management within each of the parallel threads resulting in an incomplete view of what has changed in each release and why. It therefore follows that minimising parallel development risks is only achieved if each release is under formal configuration management control.
To facilitate managing the parallel releases the configuration management process must identify the following for each release:
· All changes applied to each release.
· Why these changes were applied. This should cross refer to a help desk call or a project id.
· The items impacted by each change.
· When the change was applied.
· Who applied the change?
In addition to the above the configuration management process must be supported by the correct infrastructure. The infrastructure is needed to minimise accidental release cross over.
The infrastructure requirements to support parallel development are relatively simple to specify; each thread of parallel development must have its own set of development and test environments. These environments must be configured to prevent the opportunity for accidental release cross over.
The following diagram shows the environment schematic to support three parallel treads.
The above diagram shows the environments needed to support three parallel threads. Each thread has its own development and test ‘silo’.
Each silo contains the physical development and test environments and also includes the library for the source that is being modified for each thread.
The above diagram assumes that the live environment will only contain a single release of each application and that this release is supported by a single pre live regression test environment.
Given that only one pre-live regression test environment is provided then the above configuration will not allow any releases into live from any of the silos while the regression test environment is being used for a future release. Therefore the regression test process must be defined to have as short a life cycle as possible or else emergency release into live will be delayed.
The above schematic assumes that all threads will follow the same life cycle. This is not a mandatory requirement and it is permissible for each thread to have its own life cycle supported by its own environments. For example one of the silos may be configured to support emergency maintenance releases to live and be supported with a single test stage rather than three as shown above.