The following are the Release Management governance principles.
The following chart provides an overview of the different release management governance forums.
Governance Group | Purpose | Who | Frequency |
Change Approval Board | To approve change requests into a Release. | As defined Release Manager | As defined |
Architecture Board Meeting | To confirm:
| Release Manager AMS SDM Lead Architect | Weekly initially moving to Monthly |
Release Planning | To confirm the scope of each Release before it is initiated and to conduct Release forward planning. | Release Manager AMS SDM Project SDM Manager Operations | Monthly |
Release Status Meeting | To manage the Release through the various phases, checkpoints, environments, and to confirm that all required sign offs are in place. | Release Manager AMS SDM Project SDM Others stakeholders as required (e.g. 3rd parties, Operations, Process Owners, etc.) | Weekly |
Governance Meeting | To communicate
| Release Manager
Super Users Global Template Super Users Global Operations Reps / Process Owners | Monthly |
Below is a high level overview of the approval inputs into the Release Process.
Approver | Area | Responsibility |
Change Approval Board (CAB) | Country Go-lives, Major new functionality, System enhancements, Support Packs | Responsible to approve and priorities across Releases. |
AMS | Incidents | Responsible to priorities incidents into Releases. |
Release Manager | Release Scope | Responsible to finalize the combined Release list. Where conflicts arise, the Release manager is responsible to escalate to the CAB for resolution. |
Once a Release is frozen and in progress, the Release Manager will be responsible to ensure that the checkpoint criteria is met prior to releasing transports for Minor and Emergency Releases into the next environment. For Major Releases, the current project managers will be responsible for approving the release into the next environment, up to Pre-Production. The Release Manager will be responsible to approve the movement of transports into Pre-Production and Production for all Releases – Major, Minor, and Emergency.
Major and Minor Releases must pass the Release checkpoint criteria before they will be accepted for migration into the pre-production and production environments.
The Pre-Production environment is owned by AMS and will be used for regression testing. The pre-production environment will be refreshed from the Production environment prior to every full regression run.
Pre-Production Environment Checkpoint Entry Criteria include the following points:
Production Environment Checkpoint Entry Criteria include the following points:
The role of the Release Manager is critical to the planning and execution of the Release Management processes and governance. The purpose of the Release Manager will be to plan, manager, and co-ordinate all changes to the production environment by Releases.
The Release Manager will be responsible for the successful completion of all of the release management related activities. This includes the planning, preparation, implementation, and post implementation support. They will not be responsible for implementing the developments and changes themselves, but they must ensure that each activity is completed to plan. Therefore the Release Manager will rely on a number of individuals to execute the details and report back the status.
The Release Manager responsibilities include the following:
The AMS Service Delivery Manager (SMD) is a critical stakeholder in the release process as this role will manage and provide status updates on a significant portion of the release process. The AMS SDM will be responsible for the following areas as part of the release management process.
Operations Release Manager
The purpose of this role would be to ensure that all relevant operational readiness activities associated with a particular release were complete within the appropriate timescales. The Operations Release Manager would be responsible to provide regular status updates into the release management lifecycle and to provide the Operations go/no go for each release.The Operations Release Manager would be responsible to liaise with all relevant parties to ensure that the following activities with regards to each release were complete within the appropriate timescales.
Stakeholder | Relationship with Release Manager |
Change Approval Board | To provide the approved, planned enhancements, country go-lives, and major functionality into the release schedule |
Project Operations | To work with Release Manager through the release lifecycle providing updates and the relevant checkpoints. To be responsible for managing the contents of the Major Releases through the lifecycle and ensuring that the checkpoint criteria is met prior to the handover into the regression environment. |
3rd Parties | To provide input in the Release schedules and considerations and constraints into the Release Plan. To work within the Release timeframes and provide updates and issues to the release manager. |
AMS Service Delivery Manager (SDM) | To provide input into the Release scope (e.g. incidents) To develop the incident fixes and minor enhancements. To work with the Release Manager to manage the Releases through the release lifecycle To provide updates into the weekly Release Status Meeting. |
Operations Release Manager / Process Owners | To ensure that all appropriate training, portal content, process updates, work instruction updates, etc. are complete within the communicated Release timescales. To provide status updates into the weekly Release Status meetings. |
Communication of release contents to the team, wider stakeholders, and the business end users will be essential. The contents of a release may differ from the point at which the release scope is frozen to the point at which the release is transported into production. Therefore the final communication of the contents of the release will be critical to business operations.
Principles
The following general Release communication principles will apply.
Each Release must be carefully planned and the key dates communicated to all relevant stakeholders. Each release requires a detailed timetable of the checkpoints and cut-offs leading up to the transport into production. A detailed Release plan must be communicated to all relevant stakeholders as far in advance as possible in order that the appropriate activities may be planned and the appropriate updates and signoffs may be gathered. Stakeholders involved in each release will be expected to provide the relevant updates to the Release Manager at a weekly Release Status meeting.
Hope this series of blogs will give some insight to release management process as this approach yielded great benefits to us in couple of projects spanning multiple geography as well multi country roll out.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 |