Cloud Services

DevOps Intelligence

Release management dashboard
Published On May 16, 2024 - 11:07 AM

Release management dashboard

This topic describes features of DevOps Intelligence Release Management to facilitate informed decision-making for development managers and release managers.
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.

Dashboard view

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 aoolication 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've 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.

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.

Parameters for the Decision

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.

Tiles

The tiles serve as intuitive visual cues, highlighting parameters 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.

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:
Parameters
Current Release Status
GitHub-Kyndryl Threshold
Prev Release -
release date
% Change with Prev Release
Unclassified bugs
Code coverage
Average code smell
Code smell density
Skipped tests
Open critical bugs
Failed functional tests
Failed unit tests
User stories completed
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 vaule 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 you 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.
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.

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.

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