Managing the migration of multiple projects or project releases

Most organisations handle change that can be categorised as either Business As Usual (BAU) or Project change. Of these organisations, the majority will in fact handle multiple projects or multiple project releases at the same time. This article touches on techniques for ensuring safe handling of the go-live (migration to production) of multiple projects or multiple releases of a single project.

For the sake of this article, I will be referring to both a project and a project release as a project/s.

Handling multiple change requests across multiple projects

In order to keep the projects progressing, it is typical to assign a unit of work to a project at a change request level. If need be, the advantage is that the change request can be easily postponed or advanced to a different project by a suitably authorised user.

For an organisation using Rev-Trac, there is a built in field of ‘Proj. Rel.’ which has a direct association with the Rev-Trac request project field. The ‘Proj. Rel.’ field can contain pre-defined values to help users assign the change to a specific project. Through the ‘Proj. Rel.’ field, a suitably authorised user can control whether a project is open or closed for additional change and type of change, which can be included in the project.

Controlled Migration of projects using Rev-Trac

As always, it is recommended that users are able to approve the change request for migration as soon as it is ready for the target system.

However, in this scenario the migration job should control which projects are being migrated. This can be done by correctly scheduling a job using the variant to control migration inclusions and exclusions by the ‘Proj. Rel.’ field.

Essentially all change (despite the assigned project) will be sent to the Rev-Trac migration queue, however only the appropriate project will be sent to the target at the time migration.

Transport Sequencing

It is important to consider, common objects will often be affected when working on multiple projects.

Due to the sequence in which development occurs, there may become migration sequencing issues if changes to common objects are allowed.

If an organisation is using Rev-Trac as it’s change management tool, it is recommended that Rev-Trac Locking is turned on, to alert users of any parallel development on the same object.

In a circumstance where parallel development is necessary for a project to continue to progress, Rev-Trac’s pre-emptive OOPS checks (Overtake and Overwrite Protection System), can be used before each project migration and will alert the users of any transports from an earlier project that may need to be reimported as a result of an overwrite from the later project.

For more information about handling your migration of multiple projects or multiple project releases, please contact consulting@xrsc.com

You may also find interesting:
IT Operations Management Automation