The Release process in Service Desk behaves just like any other process – the same actions, queries and lookup behavior are available to you. For example, use the supplied process queries to see Releases by status, ordered by date, by unique identifier, or grouped by status, CI or Service as appropriate. In the same way, response levels, escalations, and notifications operate as with all other processes. When you create a new Release, as with any process, the Release is given a unique identifier, and the creation date/time and creation user details are recorded automatically.
Design Idea: Publish Releases Due Soon and Recent Releases into both your analysts' dashboards and into Self Service to communicate release progress automatically across the business.
In a Release it is typical to plan and schedule a number of activities, such as education, staff allocation, and communication. You can create these from the Release process using a Task. If you set a due date for this, consider using Reminders to warn that the work needs to be completed soon. Also add the Due Date fields to the All Releases query to provide dashboard/query visibility for these activities.
A number of items and activities around Change Management involve scheduling, so you can also pass your schedule queries into Excel for use with Project and analysis tools. Right-click any query in Console then click Export.
Some attributes on the Release process and window are specific to Release Management activities. You can add or remove these as required using Object and Window designer:
The behavior of your Release is controlled by these values – add Decisions as required to route down alternative process branches.
For more information about Decisions, see Decisions.
The Release process provides actions for the typical activities undertaken in a release; however, remember that every organization approaches releases in a different way. Some release processes are kept simple, whereas some manage every role and activity required. Where multiple activities take place in the life of the release, these are available to you from the Process Tree and the tabs on the Release window.
However, in the case of Release Management, linking Child Changes to an over-arching Release is typical. If you identify the Service as the CI on the Release, you may choose to add Changes with component CIs linked to the release. In this case, as the Changes are progressed and completed, the CIs are updated automatically using the Managed Versioning feature in Service Desk – the individual CIs as their changes complete, and the Service or released item when fully released to the business.
Design Idea: The Release process enables you to add linked Child Changes by default. You can also pause a Release, waiting for all Child Changes to be completed before automatically moving on. If you require your child changes to all be resolved or closed before the release can complete, add a Pre-condition to halt the process until All Changes are Complete.
For more information about Pre-conditions, see Preconditions.
Preconditions must look for the status of child processes to be Is Complete. Place this Precondition before your roll-out activities in the Release. This enforces the requirement that all Child Changes are completed and confirmed before rolling out the release. Alternatively, add all of the relevant CIs for the Release to the Release process using the Add Configuration Item action. These can also be updated through the Release progressing to completion using Managed Versioning; however, a Precondition cannot apply in that case.
To include a further Release Review before deployment takes place, add a new process action Release Review or Sign-Off after the above Precondition. This adds the benefit of a review from an analyst after all of the Child Changes have been completed and before progressing to the roll-out stages.
When closing a Release, the categories presented for selection are, by default, the same as the standard Change categories. You can change these as required using the Administration component.
Mature Release Management often involves roles across the IT department and beyond – sometimes including external organizations. Some Releases require new CIs to be purchased, and some require existing CIs to be upgraded. Effective Release Management at this level is very hard to achieve in any system without following Configuration Management activities to build and maintain your CMS.
See Request Fulfilment and Service Requests for advice on how to build and maintain your CMS.
When planning a release it is important to understand the start-point of the relevant CIs to the release. This is achieved by importing data from discovery tools and using the discovered values for your CI properties as the baseline for the release. See Baseline for more information on how to create this.
Also, it is hard to progress without linking between Service Desk processes. As mentioned above, you can link Changes to Releases to coordinate and manage these activities. You can also create new Asset processes where required from Release processes. The Asset Procurement process and task are provided with Service Desk to assist with this task. Furthermore the release and deployment process is integrated with request fulfilment so that requests can be logged from the release process.
As with Linked Changes described above, you can use the status of these child activities to pause and move on the Release. Apply either a Precondition or a manual confirmation action in the process when waiting for procurement activities to complete.
The Release process acts as your control mechanism for ensuring that all of the correct activities in preparing the Release happened. You can also use the Release process to control the correct steps in preparing for deployment. Use Tasks in the process design to identify the required checklist of deployment technical steps, and then complete the Tasks to confirm that the steps have been followed. Design your Release process so that you can proceed with the Release only after all of the CIs relevant to the Release have been identified, located and accounted for.
As a part of preparing the Release, it is also important to consider the software license position. You can refer to the software defined in the DML (grouping in your CMDB – see Request Fulfilment and Service Requests) to confirm the existence of software, but you can use another Release task to actively confirm that sufficient licenses do exist to proceed with the Release from a legal position. If not, the Asset Procurement process can help with the steps to request, approve and purchase additional licenses to remain in a legally and financially correct position. Consider using a final legal/finance confirmation Task before the Release is approved.
Copyright © 2018, Ivanti. All rights reserved.