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 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 click the application dropdown, which initially displays all 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 note 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 docid\ mrpffez9p f1wgundpsin 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 note\ 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 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 note 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 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 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 identifies critical release parameters and enables the setting of threshold values for at a glance go/no go decisions note 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