Working with Release Management
The release process encompasses planning, design, build, configuration and testing of hardware and software releases to create a comprehensive release strategy. Release Managers and Administrators can view releases.
Release management is responsible for designing, testing, and installing defined changes in the live environment. While change management manages the process of change, release management manages the deployment of those configuration items that are implemented by change management. A release consists of rolling out new or updated software or hardware (configuration items) required to implement approved changes. The implementation of new hardware or software releases combine the controlled process of configuration management with the communication and preparation of change management. A release is thus initiated as part of the change management process and works with configuration management.
Release management is used to distribute and manage the rollout of software and hardware across the entire IT infrastructure. In an IT environment, the goals of release management include the successful implementation of new software releases, hardware installations or upgrades, and other IT infrastructure changes that affect business operations. For example, upgrading the email server. Proper software and hardware control makes sure that licensed, tested, and version-certified software and hardware is available for use in the organization.
In Service Manager, release management provides you with all the capabilities for managing a release while still leaving the process flexible enough for you to incorporate business rules and validations to tailor the release process to fit your organizational needs.
Release management is responsible for:
•Planning the rollout of software.
•Designing and implementing procedures for the distribution and installation of changes to IT systems.
•Effectively communicating and managing expectations of the customer during the planning and rollout of new releases.
•Controlling the distribution and installation of changes to IT systems.
The following release types are supported in Service Manager:
•Major Release: Software releases and major hardware upgrades, normally containing a lot of new functionality. A major upgrade or release usually supersedes all preceding minor upgrades, releases, and emergency fixes. A major release might affect most users in the organization.
•Minor Release: Software releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes. A minor upgrade or release usually supersedes all preceding emergency fixes.
•Emergency Release: Software and hardware fixes, normally containing the corrections to a small number of known problems.
Release management encompasses the planning, designing, building, configuration, performance testing, and acceptance testing of hardware and software in order to create release components ready for implementation in a production environment. Release describes an authorized change or collection of changes to an IT service. In Service Manager the scope of a release can be:
•Standalone: All components of the release are tested, distributed, and implemented together. A standalone release might be a minor release. It does not contain other related releases
•Master: The rollout of configuration items brought about by a single major change might be broken into a master release (for the entire release project) and its subsets (or phase releases). A master release might be a major release type. The other releases under it are related releases.
For example, upgrading the entire organization to Windows 7 might be a master release project while one phase might be setting up users' computers and changing their BIOS settings (if necessary).
•Phase: A subset of a master release. For example, a software rollout can be done in phases for each location.
In Service Manager, release management uses milestones to plan and increment the release process. By default, milestones are created for major releases; however, you have the option to manually create milestones for emergency and minor releases. See Working with Milestones for best practices when using milestones.
•By default, approval workflows are defined for release milestones that are generated using the template for major releases.
•Along with the Release Review Board, stakeholders are also identified for the release.
•A request for release might come from change management. When the change is linked to the release, the schedule dates for the change are driven by the release schedule and become read-only. The Release Manager also creates release packages to roll out configuration items included as part of a change.
•Release Managers can also view the cost of the release while it is worked on, and get a final cost associated with the release upon the closure of the release or a milestone upon the closure of the milestone.
•Release Managers can also monitor and track the metrics associated with releases by reviewing the release reports.
Major (created without templates), minor, and emergency releases are not included in the approval workflow. Milestones can be created using quick actions, but they are not subject to the approval workflow. The following diagram shows the states of a release that is not major (and not created using a template):
Release Lifecycle States
The process to create and implement a release generally is:
1.Plan the release.
2.Create a release request.
3.Add release milestones.
4.Approve the release request.
5.Implement the release.
6.Review the release for successes and lessons learned.
7.Close the release request.
Viewing Release Records
1.Log in to Service Manager as a Release Manager.
2.Open the Release workspace. A list of all the releases, arranged from the highest release ID appears.
3.Double-click an item from the list to view details.
Was this article useful?
Copyright © 2019, Ivanti. All rights reserved.