Service Manager

Home

This is the latest version of the help for Ivanti Service Manager 2018. If you cannot find some of the features described in the help, you may be using an older version of the application. To upgrade the application, click here.
To view the help for the latest version of Service Manager, click here

Working with Releases and Release Management

•About Release Management

•About the Release Lifecycle

•Viewing Release Records

•Creating Releases

•Working with Milestones

•Canceling a Release

•Approving Releases

•Using Gantt Charts

•Linking Configuration Items and Services to a Release

•Working with Related Releases

•Working with Release Packages

•Default Release Templates

•Release State Transitions Reference

About 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 the following:

•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.

About Milestones

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.

•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.

See Working with Milestones for best practices when using milestones.

About the Release Lifecycle

Release Lifecycle

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