Using Release Management v2

  • Release version: Xanadu
  • Updated July 31, 2025
  • 2 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Using Release Management v2

    The Release Management v2 plugin in ServiceNow provides structured tables and functionality to plan, manage, and execute software releases efficiently. It organizes release information, tasks, and work artifacts, facilitating governance throughout the release lifecycle.

    Show full answer Show less

    Key Features

    • Product Records: Products group related releases and work artifacts. They can be linked to Configuration Items (CIs) in the CMDB to connect release activities with incident, problem, and change processes. Defining a product is optional; releases can be enterprise-wide or span multiple products without product definitions.
    • Release Planning: Releases are defined under products (if used) and can include child releases or release phases, enabling detailed management of complex release structures.
    • Release Phases: Releases can be divided into multiple phases (e.g., requirement gathering, design, development, testing, deployment), supporting governance and smooth execution. Each phase contains tasks that must be completed for phase completion. The phase structure can be customized based on organizational processes.
    • Release Scoping: Before execution, define the release scope by associating relevant work artifacts such as projects, epics, stories, enhancements, and defects. This ensures clarity on what is included in the release. Note that from the New York release onward, scoping using SDLC or Scrum modules is not available.
    • Release Hierarchy Visualization: The Release Hierarchy related list allows managers to visualize releases, phases, and tasks in a hierarchical format for better oversight.

    Practical Considerations for ServiceNow Customers

    • Use product records to logically group releases and link to CIs for integrated tracking across IT processes, but defining products is not mandatory.
    • Plan releases by defining phases and tasks tailored to your organization’s release methodology (waterfall, merges, etc.).
    • Scope releases carefully by adding relevant development and issue artifacts to maintain control over what is delivered.
    • Keep release phases and tasks updated regularly to ensure accurate progress tracking and release governance.

    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.

    Important:
    Starting with the New York release, scoping a release using SDLC or Scrum (Agile Development 1.0 (com.snc.sdlc.scrum.pp)) is not available.

    While scoping the release, you can use the Release Hierarchy related list on the Release Form to view the release as a hierarchy.