Release Management in ServiceNow (and other cloud systems) is the key to success in implementing changes. It supports Change Management and organizes the process of uploading any modifications to the production environment.
Release Management – introduction
Release Management first requires a remote session with the customer to identify customer’s needs and expectations. Based on these, we make the following decisions:
- How often should the upload take place?
Frequency can depend on change queue volume. We recommend a weekly basis to keep implementation continuity. However, if the customer wants to upload changes with a different frequency, we can adjust the plan. - What is the best day of the week and time to upload the changes?
To reduce the impact on the instance users, while choosing the best date and time, we consider different time zones and customer’s availability. - How much time before release the customer should confirm upload of the change to the production instance?
We highly encourage customers to test every change in the UAT state and confirm if it works properly or not. Moreover, we recommend to determine the final release scope 1 business day before the release date. - What are the other expectations related to the process?
We need to know what are the other suggestions and how we can include them in the process.
After the session with the customer and discussing all details, we can prepare a draft proposal of a process version. The customer reviews it, and either proposes own corrections or accepts the prepared plan.
Change Management
We group normal changes in releases. Incident resolution and urgent changes are uploaded to production as soon as possible to fix the system failure or implement a business-relevant modification. We use our version of Release Management in ServiceNow instance which is a very convenient tool to take control over the changes and keep the customer informed.
Releases should have a consistent naming convention. Every release should have a unique name, assigned person responsible for managing it on the SPOC side and set date. Every change request record has the “Release” field on the form to provide the proper release number. All changes within a release, can be checked in the release record from Related List.
Release & change planning
On our side, we can see release size based on changes estimates and developers involved in changes implementation. It’s good to plan releases at the beginning of the month, and organize them in the system to observe the delays that may affect the original plan.
The customer should early confirm all changes in the UAT state, to make us able to upload it properly to the production instance. In case of confirmation delay, we recommend its upload in the next planned release.
If the customer finds any bug, our Maintenance & Development Team implements fixes as soon as possible, implementing the change in the next release. The fixes application time depends on issues complexity.
Release & change implementation
We upload all the changes in maintenance windows first agreed with the customer. Thus the instance users know when they can expect system modifications. If any changes in the release are not uploaded to the production instance, we move them to another release record.
Release reporting
The release manager on the SPOC side provides Release Notes to the customer. The notes contain information about the implemented changes, possible conflicts or issues, and the list of unimplemented changes with the reasons.
All information is visible on the ServiceNow instance – releases have states and fields providing customer with relevant information.
Benefits of Release Management
Release Management brings a number of benefits to each organization:
- We take control over changes uploaded to production instance what reduces the risk of unexpected incidents.
- We keep the customer informed. It generates the satisfaction – the customer knows which changes were implemented and which were not, knowing the reasons why that happened.
- Instance users know when they can expect changes in the system.
- If something happens, we can identify faster which change solution was the exact source of the issue.
- We can track which changes got stuck in states, e.g. UAT for a long time and speed up the customer’s actions.
