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:
Scope in on what matters to you
“clean” the irrelevant data - see Appendix A Below (How to Ignore irrelevant code)
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
View the Quality Risks within your code
Install the SeaLights Code Viewer Chrome Extension on your personal computer with
There are two main use cases to use Release Quality Analytics:
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
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
Reminder: your SCM should be updated with the SeaLights extension in order to get the Quality Risks displayed in your pull requests.
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.
Click on the line indicating the Quality Risks and you will get the details of those Quality Risks
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
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.
Open the dashboard and find the relevant application/component
Click the quality gates icon on the control panel to the right of the application raw
Define the failing criteria for this application/component in the quality gate definition dialog
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.
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.