Services

Explore Kyndryl Bridge Services

Release management module
Published On Apr 28, 2026 - 1:51 PM

Release management module

Navigate a view of past releases and compare them to current releases to understand DevOps team performance at every phase of the DevOps cycle.
Release management is a pivotal discipline within the DevOps framework. This process ensures that software builds traverse smoothly from the development environment through various stages, culminating in a production-ready state. In modern agile and rapidly evolving development cycles, where software updates can be frequent, release management becomes invaluable. It's not just about transitioning code; it's about confirming that this code is stable, aligns with quality standards, and meets business needs.
DevOps intelligence brings a nuanced dimension to release management, transforming it from a mere process to a strategic orchestration. Embedding structure and defined checkpoints ensures that releases are scrutinized and validated at every step.
From development managers to release managers, stakeholders can quickly assess a release's risk profile, ensuring informed decisions without silos. This provides an overview of the risk profile for a single application, which can be selected from the global application menu. We have captured nine different parameters across the Plan and Test categories. With a consistent release nomenclature, you can understand how the release is performing in these nine parameters compare to their respective thresholds. These thresholds can be set at the application level and configured by an administrator.

Dashboard composition

When you navigate to the Release Management Dashboard, it is not populated. You must select a release from the
Dashboard View
, which is displayed as an interactive collection of specification displays. Use the following procedure:
  1. Click the Application dropdown, which initially displays
    All data.
  2. Select the application from the dropdown list.
  3. Select the release from the Releases dropdown.
  4. Select the environment from the Environments Dropdown.
The service displays all parameter values, a gauge chart and the Release Decision Parameters table.
The releases that are available for assessment are limited to those that have occurred in the previous 180 days.
When you land on the release management page, you'll encounter drop-downs to select the desired
APPLICATION
,
RELEASES
 and
ENVIRONMENTS
. Plus, you'll observe a gauge chart that measures from
LOW
 to
HIGH
 and a unique table labeled
Parameters for the Decisions
. Ensure you have picked the right application, release and environment.

Gauge chart

The gauge chart on the release management dashboard quickly indicates the risk level of your release as High, Medium, or Low. High risk suggests significant issues that might impede the release, Medium indicates moderate concerns, Low implies minimal risk, and No Risk indicates all risks have been eliminated, aiding in swift decision-making for release progression in DevOps.
Key risk assessments on the gauge chart include:
  • High risk
    :
    • 80% (or more) of parameters are below the acceptable threshold.
    • The presence of severity 1 or 2 bugs compounds the risk.
  • Medium risk
    :
    • The release exhibits concerns, with over 50% of its parameters falling below the threshold, warranting closer scrutiny.
  • Low risk
    :
    • Indicates a relatively robust release state, with only 20% (or more) parameters below the threshold.
  • No risk
    • Indicates all risk has been eliminated.

Secure Alerts

The Release dashboard supports Secure Alerts, enabling visibility into security issues detected for a release. The dashboard supports viewing and tracking secure alerts so teams can identify and address risks before approving a release.
Secure alerts are present in the following dashboard elements:
  • Gauge Chart: The risk calculation presented displayed in the gauge chart is affected by data from secure alerts.
  • Secure Alert tile array: A row of individual tiles that present identified security vulnerabilities.
  • Release Decision Parameters table: Table line items that present identified security vulnerability details.
For more details refer to Secure Alerts.

Release approval

With
Editor
 role, you can approve a release for a specific application, environment, and release. All it takes is to select the
Approve release
 button. Once you approve the release, you'll see the "Decision history" button.
When you approve a release, it's final. You can't revert or duplicate the approval for the identical application, release, and environment trio.

Decision history

As an
Editor
, once you approve the release, the system intuitively updates its interface. Your
Decision History
 is a detailed archive, showcasing:
  • The specific determinations you've made for each release.
  • The exact timestamps of when you sanctioned each approval.
  • The reasons and considerations that influenced your decisions.
The page presents two tabs that present information to assist with release management:
  • Release Decision Parameters: Tabular data governing release management decisions with details.
  • Deliverables: The composition of releases.

Release Decision Parameters

The Release Decision Parameters DevOps Intelligence Release Management supports the following elements to assist with release decisions:

  • Parameters
    : These are the distinct elements that factor into your release decisions. For convenience in evaluation, you can sort this column.
  • Current Values
    : Represents each parameter's real-time metrics that contribute to the release assessment. This column has been made sortable by severity to aid in your evaluation process, enabling a more nuanced understanding.
  • Default
    : Refers to the benchmark settings Kyndryl has standardized for each parameter. This column remains static, designed to provide a consistent reference point, and is not subject to sorting.
For a deeper analysis or to share with your team, you can
Download
 a comprehensive list detailing each parameter, its current value, and its threshold value. This information is conveniently provided in a CSV format, ensuring ease of use and integration into any data analysis tool or platform you prefer.

Performance Metrics Tiles

These metrics highlight parameters such as Static Scan, Secure Alerts, and Container Vulnerability Scan that have descended below their designated threshold values. By glancing at these tiles, you can quickly ascertain areas that might require your attention, ensuring that no critical detail goes unnoticed during the release decision-making process.
Each tile contains a hot link that navigates to a details page, providing detailed information about the metrics.

Release Decisions Parameters table

The Release Decision Parameters table contains reports values for specified parameters within the context of release status and thresholds as shown in the following
representative
 table, which can vary depending on the application:
Parameters
Current Release Status
di_application
 Threshold
Prev Release :
latest
% Change with Prev Release
Open critical bugs
1
10
2
50%
Unclassified bugs
0%
5%
25%
100%
Code coverage
95%
90%
90%
5.6%
Average code smell
50
5
90
44%
Code smell density
5%
10%
6.9%
27.7%
Skipped tests
31.6%
0%
41%
24.2%
Failed functional tests
21.4%
0%
16.7%
28.6%
Failed unit tests
20%
5%
0%
100%
User stories completed
95%
90%
93.3%
33.7%
Critical Vulnerabilities
16
0
25
Denied Licenses
0
0
NA
NA
Secure Alerts
NA
0
NA
NA
Table header elements
  • Parameters:
     Supported parameters, the values of which collectively determine release decisions.
  • Current Release Status:
     The values of the parameters listed in column one.
  • GitHub-Kyndryl threshold:
     The minimum acceptable value to allow a release.
  • Prev Release -
    release date
    :
     The values of the parameters listed in column one for the previous release
  • % Change with Previous release:
     The difference in the value of the parameters listed in column one between the current release and the previous release, expressed as a percentage of the value in the previous release. For example, if the code coverage for the current release is 70% and the code coverage for the previous release is 100%, the release delta has degraded 30%.
Release parameters
  • Unclassified Bugs:
     Denotes those bugs that currently exist without a designated severity level, prompting a review to categorize them appropriately.
  • Skipped Tests:
     Reflects the tests intentionally overlooked during the testing phase. It indicates the percentage of bypassed unit tests, pointing to potential risk areas.
  • Failed Unit Test Cases:
     Pinpoints areas in your code that might be error-prone. It represents the proportion of unsuccessful unit tests compared to the total executed.
  • Failed Functional Tests:
     Offers insight into the robustness of your application's functionalities by showcasing the percentage of functional tests that did not pass.
  • Open Critical Bugs:
     A direct count of pressing unresolved issues. These bugs have been flagged with severity levels 1 and 2, signaling immediate attention.
  • Unclassified Bugs:
     Denotes those bugs that currently exist without a designated severity level, prompting a review to categorize them appropriately.
  • Average Code Smell:
     Computes the mean ratio of code anomalies to the cumulative count of technical services. This helps your gauge code quality and areas needing refactoring.
  • Code Smell Density:
     Focuses on code quality by indicating the percentage of code discrepancies encountered per 100 lines within the specific technical service(s).
  • User Stories Completed:
     Represents the percentage of user stories that have been completed out of the total number of user stories that have been created linked with the specific release.
  • Critical Vulnerabilities:
     Lists only critical-level vulnerabilities found in container images, filtered based on the selected application and its corresponding release.
  • Denied Licenses:
     The list of licenses that are restricted or denied by policy, depending on the specific application and release version selected.
  • Secure Alerts:
     Notifications that address the dynamic nature of threats as they occur, providing an immediate understanding of your hybrid IT estate.
Parameter table column settings
The table view can be customized to show or hide columns displayed in the table. Click the gear icon above the table on the right to display an array of column labels. Each column label has an associated checkbox. Check the associated box to display a hidden column or uncheck the associated box to hide a displayed column.
By default, only the
Parameters
,
Current Release Status
 and
GitHub-Kyndryl Thresholds
 columns are displayed.
Parameter details
Details are available for each release parameter to enable a more thorough analysis than is possible using the raw statistic and comparison to the previous release presented in the table. The service might report that the Skipped tests parameter, for example, is 5.2% and that this represents a 29.6% improvement over the last release.
While this information is useful, it doesn’t provide a sense of whether tests are skipped more often in the case of some services compared to others. If some services sustain a higher incident of skipped tests than others, the release manager will likely be prompted to investigate the reason. In the case of Skipped tests, this additional information is available.
The right column contains a vertical ellipsis. To see details use the following procedure:
  1. Click the ellipsis to display an overflow menu with a View Details option.
  2. Click
    View Details
    . The service displays a Release Management / Parameter Details panel.
The panel presents the following details:
  • Parameter name
  • Value for the current release
  • Filter: Select from Technical services (all services) or individual services
  • Details table: Details vary by parameter
Details table
The following table explains the details available for each release parameter:
Release Parameter Details
Release parameter
Available details
Why details are useful
Code coverage
Execution Date, Coverage, Duration, Tool Engine
This parameter helps the release manager to understand which Technical service is accounting for the least code coverage for a release. Development managers can then assess details and direct the team to focus on improving the coverage for that specific service.
Skipped tests
Test Run ID, Technical Service, Total, Skipped, Tested at, Tool Engine.
Understanding whether some services sustain higher rates of skipped tests can guide release managers to understand which services are the bottleneck for the entire release. Approving high skipped test rates can result in high possibility of incidents when application is in production,
Failed unit tests
Test Run ID, Technical Service, Total, Failed, Tested At, Tool Engine
The details page helps to identify which services have higher failed unit tests. High failed unit tests indicate potential defects, risking stability and reliability of the software in a production environment.
Failed functional tests
Test Run ID, Technical Service, Total Failed, Tested At, Tool Engine
The details page helps to identify which services have the highest failed functional test rates. High failed functional test rates suggest critical features might not work as intended, risking user dissatisfaction and product credibility, post-release.
Open critical bugs
Bug, Summary, State, Technical Service, Severity, Created By
Understanding the severity of a collection of open bugs by service enables insight regarding the general quality of service code and implies whether further investigation into the service is warranted.
Unclassified bugs
Bug, Summary, State, Technical Service, Created By, Assigned to
Understanding the list of bugs which are unclassified in one single page with respect to an upcoming release helps development managers be prepared for any unknown issues. He can go through the list and assign appropriate severity within the parent tool.
Average code smell
Technical Service, Execution Date, Code Smell, Duration, Tool Engine
Understanding chronically high code smell for a specific service indicates that investigation of code quality for that service is warranted.
Code smell density
Technical Service, Execution Date, Code Smell Density, Duration, Tool Engine
Understanding chronically high code smell density for a specific service indicates that investigation of code quality for that service is warranted.
User stories completed
User Story, Summary, Feature Name, Technical Service, Created On, Assigned to
The details page provides the list of user stories and associated features which the team have completed as [art of the release.
Critical Vulnerabilities
Technical Service, Application, Image Name, Release Name, Total Vulnerabilities, Critical, High, Scanned on, Secure Engine
Critical-level vulnerabilities found in container images are one of the most important variables in the
go-no go
 decision process. Severe consequences are possible if the threshold is breached.
Denied Licenses
Technical Service, Application, Image Name, Release Name, License Detected, Critical, Scanned on, Secure Engine
This parameter represents the list of licenses that are restricted or denied by policy, depending on the specific application and release version selected. This is a necessary factor in release management.

Configuring the Release Management parameters

Kyndryl DevOps Intelligence Release Management enables
Go/No-go
 decision making on the part of the release manager. Release managers must understand based on identified parameter values whether a given release should proceed. DevOps Intelligence identifies critical release parameters and enables the setting of threshold values for at-a-glance
Go/No-go
 decisions.
The application provides default release decision parameters tenant-wide, which can be modified for each application by administrators assigned the
Release Manager
 role.
You must be assigned one of two roles to configure these parameters:
  • DI Admin:
     You can configure these parameters from the Configure Technical Services page (DevOps Overview → Settings & Utilities → Configure Technical Services) for the entire tenant across all applications.
  • DI Release Manager Role:
    You can configure these parameters from the Release Management page for each application.

Deliverables

The Deliverables tab presents a deliverables table listing all components in the selected release with the following information:
  • Features/Defects:
     The Feature or defect ID, which is a hotlink to details for that feature or defect.
  • Description:
     A summary description of the item.
  • Type:
     The type of item that is being release, for example Feature, Defect, or User Story.
  • Current State:
     The current state of the item such as Ready for Staging or Resolved.
A filter is available to narrow the elements by type:
  • Select all (default)
  • Issues:
    • Feature
    • User Story
  • Defects

Editing the release parameter configuration

On the Release Management page, the parameters initially listed in the Release Decision Parameters table are set for the entire tenant by a user who has been assigned the DI Admin role from the Configure Technical Services page. If you have been assigned the DI Release Manager role, you can edit these parameters for a specific application, which is the one you selected when you first arrived at the Release Management landing page.
Click the
Edit Configurations
 button located above the table on the right. The application displays an edit canvas:
Make the necessary changes and click
Save configuration
.
Do you have two minutes for a quick survey?
Take Survey