Using Release Management v2
Summarize
Summary of Using Release Management v2
The Release Management v2 plugin (com.snc.releasemanagementv2) provides structured tables to manage planned releases and the tasks needed to execute them within ServiceNow. It enables organizations to plan, govern, and track releases through defined products, releases, release phases, and work artifacts.
Show less
Key Features
- Product Records: Products serve as reference points grouping releases and related work artifacts. Products can optionally be linked to Configuration Items (CIs) in the CMDB to connect release information with other IT processes such as incident, problem, or change management.
- Release Definition: Releases are defined under products and can include multiple child releases or release phases. Releases can be enterprise-wide or associated with multiple products without requiring a product definition.
- Release Phases: Multiple phases can be created per release to model release governance and execution workflows. Phases reflect stages such as requirements gathering, design, development, testing, and deployment. Each phase contains release tasks that must be completed to progress.
- Release Scoping: Before execution, releases are scoped by associating relevant work artifacts like projects, epics, stories, enhancements, and defects. This scoping defines the release content and helps differentiate between minor and major releases.
- Release Hierarchy Visualization: The Release Hierarchy related list on the Release Form provides a clear view of the hierarchical structure of releases, phases, and tasks.
Important Considerations
- Defining a product is optional; releases can be managed at an enterprise level without product association or with multiple products linked.
- Starting with the New York release, scoping releases using SDLC or Scrum (Agile Development 1.0) is no longer supported.
Practical Application for ServiceNow Customers
ServiceNow customers can leverage Release Management v2 to streamline release planning and execution by:
- Organizing releases under products to align with business units or service offerings.
- Structuring releases into clear phases and tasks to enhance governance and tracking.
- Scoping releases effectively with relevant development and operational work items to ensure all necessary components are included.
- Connecting release data with configuration management through CIs for integrated IT service management.
This structured approach helps improve visibility, coordination, and control over complex release processes within ServiceNow.
The Release Management v2 plugin (com.snc.release_management_v2) provides release tables which store information about the planned release and tasks that are required to execute the release.
Product
Use a Product record in Release Management to store information about a product for reference purposes and groups all the releases and work artifacts for the product.
You can use the Configuration Items reference field to link the product with a corresponding CI in the CMDB. Each CI keeps information about how it relates to other CIs, and can track any incidents, problems, or changes related to it. Specifying a CI for the Product connects information from the release process to other processes in the instance.
Defining a product is not mandatory to manage the release process. A release can be an enterprise release in which it is associated with all products or services, or it can be associated to more than one product as well. In either of these cases, defining a product is not mandatory.
Once releases are defined for a product, the Product Hierarchy related link displays the hierarchy of releases, release phases, and release tasks associated with the product.
Release
Once a product is defined, you can plan and execute a release. Start by defining a release for the product and add child releases or release phases for the release. Then, scope the release by defining work artifacts for the release.
Release Phase
Define multiple release phases for a release for release governance and smooth execution.
For example, if the release is managed more like a waterfall process, the release phases could be requirement gathering, design, development, testing, build, acceptance, and deployment. For each phase, there can be release tasks associated to it. The phase gets completed as and when all tasks are completed for a phase. Release managers must keep the release phases updated.
If the release is divided into multiple merges, the phases could be merge 1, merge 2, merge 3, and so on. The type and number of phases would depend upon the release management process of your organization.
Scoping a release
Before starting the release execution, you must define scope of the release. Scope of a release includes the work artifacts such as projects, epics, stories, enhancements, and defects that are a part of the release.
For example, a minor release might only have a few problems and enhancements whereas a major release might have multiple projects or epics associated to it.
While scoping the release, you can use the Release Hierarchy related list on the Release Form to view the release as a hierarchy.