All the processes that apply to single threaded development still apply. Parallel development introduces the need to perform these on a much more formal manner and also introduces the following additional processes.
Formal reports must be generated for each silo. These reports must specify the following for each and every item found in the silo.
· Version of item found in the silo. This may be identified using a version number of by using a combination of size and date stamp. Tracking the version of items will enable the CM team to identify what has and has/not changed within a given silo.
· Why each change was applied. This must always cross-refer to a valid change authorisation process. In our case this must be a CM Tracker record number.
· Software items modified for each change. This should itemise the individual programs, files and tables that were modified for each change.
· Who and when the change was applied. These are not mandatory but can be very helpful when trying to reconcile changes across releases.
The above reports must be generated on a regular basis and summarized to provide the following information:
· New items created in each silo.
· Existing items modified in one silo only.
· Existing items modified in two or more silos.
Summarising changes into the above manner will identify items changes that can be applied across releases with making any code change and those that require manual retrofitting.
The synchronisation process is responsible for releasing changes between the various silos to ensure that they are always in step. The synchronisation process only releases new items and those items that have changed in a single silo only.
When performing synchronisation it is important to identify the order in which the releases will be applied into live. The synchronisation process copies new and unchanged items from the releases that are planned to go live first to those that are going live last. Items that have undergone parallel change in two or more silos are not released between the silos using this process; these changes require manual retrofitting.
When synchronising two or more silos one has the option of performing the synchronisation as soon as the changes are created or one can delay the synchronisation until the change has been tested or applied to live. The following diagram shows the potential synchronisation paths.
Path “A” provides early synchronisation between R1 and R2. Path “E” provides late synchronisation between R1 and R2.
Whilst path “E” provides the more stable code to the later release. Path “A” provides early synchronisation but the code provided to the later release may require future additional synchronisation if and when this code undergoes bug fixes in during development and testing.
Please note that the synchronisation process must apply to all items, i.e. code, database objects and data.
Retrofitting is similar to synchronisation except that the changes from one silo cannot be copied across to other silos but will need to be applied manually. The differences between synchronisation and retrofitting derive from the fact that in synchronisation one is copying items that have changed in one silo only and in retrofitting one is reapplying a change to items that have been modified in both the source and target silo.
Mod marking of source items, including database objects and data, is essential to enable effective tracking of parallel development. All source items must be annotated with the following for each and every change.
· Reason for change. This should cross-refer to the CM Tracker record.
· Author of change
· Date of change
The above annotations must be maintained for normal release development changes and for each synchronised and retrofitted change. Mod marking for synchronised and retrofitted changes is essential and the following are important guidelines to follow:
· Items must be mod marked to include annotations for each applied synchronised or retrofitted change. This will ensure that the history in the source and target silos is in step for applied changes.
· The target items must be mod marked to include annotations for unnecessary synchronised and retrofitted changes. Again this will ensure that the history in the source and target silos is in step. A note should be added to these annotations to confirm that the change has not been applied and also provide details of why the change application was considered to be unnecessary.
Mod marks should be applied using a standard notation, preferably preceded with a history block marker and using a comma separated filed format. Each line of history must be fully documented. This requirement is not mandatory but is very important if one wishes to create a code scanning tool to summarise the histories of items with the aim of confirming that retrofitting and reconciliation has been performed.
This is a very complex process and is only needed if the level of change across the releases is high. The need for this process is increased as the point at which synchronisation and retrofitting is moved up the life cycle.
The previous sections stipulate that changes should be identified as new, changes in one release only and changes in parallel releases. These reports can be viewed on a change by change and items by item basis or one can view the complete history. Source and target impact analysis is when one generates these reports on the basis of the complete history. Following is an example of how this process works.
The above diagram shows sine source items. Those that are new in one release are marked as “N”, those that have changed in both releases are marked as “P” and those that have changed in the current release only are marked as “C”. The above items have been modified for three separate changes, EIT500, EIT600 and EIT700.
If the retrofitting and reconciliation were performed on an item by item basis then one would have copied across all new and changed items from the current release to the next release.
If one performed retrofitting and reconciliation on the basis of a single change request then EIT500 changes would have been synchronised from the current to the target release with any complications.
If source and target impact analysis is performed across items and changes then one would need to synchronise and retrofit EIT500, EIT600 and EIT700 from the current to the next release. Splitting the changes into smaller groups would produce inconsistencies in the target environment.