For release managers and QA leads who need to know where a version is and what was found in it.

Your setup

Three Certyn environments: dev, staging and production. Production is marked as a production environment.
Your deploys set each environment's version, for example 2.6.0.
Certyn runs test these environments.
You want one view of where 2.6.0 is and what it brought.

Say this to Certyn

Where is 2.6.0 now? When did it reach dev, staging and production, and which bugs were found in it on each?

Lists the releases and where each one is (app.release.list): each environment, when the version first reached it, and if it runs there now. The first time on a production environment is the ship date.
Reads each environment's version now and its last 10 deploys with changelogs (app.environment.get), or the deploy history of all environments (app.metrics type versions).
Gets the release's issues and runs for each environment (app.release.get with environment).
Answers with one row per environment: version now, when 2.6.0 arrived, issues found in 2.6.0 there.

Where each version runs, and when it moved.
"Found in" on each issue: the version its run tested. A bug found on staging keeps 2.6.0 after staging moves to 2.6.1.
In the app: Releases in the top menu lists each release with where it is, its verdict and what was found. A release page shows its environments, runs and issues. The Issues page filters by "Found in".

Certyn knows only the versions your deploys report. With no version on an environment, runs and issues have none. Set it from your deploy: see Run a Certyn Process After Each Deploy.
A deploy of 1.0.0, v1.0.0 or a 40-character commit SHA stays in the deploy history but does not become a release. Use real version names, or ask Certyn to create the release.
Issues found by runs get "Found in". An issue you file by hand in the chat has none.
Names must match exactly: 2.6 and 2.6.0 are two different releases.