Release management module
Release management module
Navigate a view of past releases and compare them to current releases to understand the performance of your DevOps team at every phase of the DevOps cycle over time, gaining insight that can yield recommended action.
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 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:- Click the Application dropdown, which initially displaysAll data.
- Select the application from the dropdown list.
- Select the release from the Releases dropdown.
- 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.
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 value to allow a release.
- Prev Release -The values of the parameters listed in column one for the previous releaserelease date:
- % 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.
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:
- Click the ellipsis to display an overflow menu with a View Details option.
- ClickView 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 | 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
