Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Original content taken from Dashboard (Quality Gates & Quality Risks Management)

Introduction

The SeaLights’ Release Quality Analytics main usage is to enforce your quality standards in your organization or among your teams.  Quality Risk is a recent code change that none of your tests are covering it, you should not let these Quality Risks reaching production.

Steps to Take Before You Start Using Release Quality Analytics:

  1. Scope in on what matters to you

    • “clean” the irrelevant data -  see Appendix A Below (How to Ignore irrelevant code)

  2. Verify you get Quality Risks for your untested code changes

    • Click on the Quality Risks and see that you get a list of files including those untested code changes

  3. View the Quality Risks within your code

    • Install the SeaLights Code Viewer Chrome Extension on your personal computer with 

    these instructions.

There are two main use cases to use Release Quality Analytics:

  1. Test your code before merging it into the master branch

    • Validate during a pull request that the code changes done in your developer branch are tested 

  2. Creating a risk-free release pipeline 

    • Validate that the code which was added or modified in your last build is tested in your pipeline.  Builds with Quality Risks should be blocked in the CI automatically

Use Cases


Go/No-Go Decision - Pre-Merge - Pull Request


  1. Reminder: your SCM should be updated with the SeaLights extension in order to get the Quality Risks displayed in your pull requests.

  2. When you open the Pull Request, you will get an indication from SeaLights for new Quality Risks found in case your code changes, introduced in the pull request, were not tested.

  3. Click on the line indicating the Quality Risks and you will get the details of those Quality Risks

  4. When you get into the code viewer you can see the code areas that were modified and no test is covering them. You should now add or modify your tests to also cover this change, this may detect a bug at this stage before you merge it into your master branch.

        

Go/No-Go Decision - Post Merge - Build Promotion


  1. As a prerequisite for taking an automatic go-no-go decision based on Quality Risks, you may need to first define the quality gates for a given application/component.

    1. Open the dashboard and find the relevant application/component 

    2. Click the quality gates icon on the control panel to the right of the application raw

    3. Define the failing criteria for this application/component in the quality gate definition dialog

    4. Once defined, you need to follow a few builds and verify that your quality gate criteria are defined properly and build status in the dashboard is reflecting the correct go-no-go definition.

  2. Once this is confirmed and you are ready to enforce your build breaking criteria in the CI itself, you may use an API call (described in this link) from your CI to SeaLights and based on the result you may break the promotion of the given build.

  • No labels