Releases and tests

Full guide on the /releases/como-funciona screen ("How it works" button in the release list).

• Release: a version of a project (e.g. App 2.4.0), with a planned date, linked issues, test cycles and release notes (a draft generated from the resolved issues, editable, to copy or send to the customer).
• A release's path (status): Planned (planned: in the plan, nobody working on it yet) → In development (in_development: the team works on the issues) → Testing (staging: QA tests in test cycles; it used to be called Staging) → Approved (approved: the gate recorded APPROVED, ready to go live) → In production (production: it went live). Canceled (cancelled) leaves the path and can go back to Planned. The PO/PM moves the status; Approved normally comes from the gate's APPROVED decision; In production requires the gate APPROVED (without it, only an admin, with a justification), except for OTA.
• Which one is live and which is next (the release's moment): version and OTA are separate tracks: in each project, the most recent version in production is the live version and the most recent OTA in production is the live OTA (current, "In production"); the others in production on the same track are previous (previous). The next one (is_next, "Next" badge) is the one going live next on its track: the furthest along the path (Approved, then Testing, In development, Planned) and, on a tie, the one with the earliest planned date. The release list is split into In production, Testing (includes Approved), Next and Previous (includes Canceled).
• Update without the store (OTA): a release with kind "ota", for what reaches devices without going through the App Store or Play Store. Create a new release for each OTA, with the version it carries (e.g. 2.4.1) and the build. It can follow the path with a test cycle and gate, but doesn't have to: an OTA hotfix goes live in hours and QA validates afterwards, already in production. That's why an OTA goes to In production from any step, without a gate decision, and can even be created directly as In production (status "production") when it was already sent. Any release that already went live outside tracker (a backend deploy, a version published earlier) can also be born In production, with the date it went live. Its page shows validation through the linked issues: how many are in Ready for QA, Testing, Approved and Failed. Once published, it becomes the project's live OTA and the previous OTA moves to Previous; the store version stays live, because they're separate tracks. A normal version (store or deploy) is kind "version", the default.
• On the release page, the top says in one sentence where it is, which one is live and what the next step is (e.g. create a test cycle, finish the tests, fix what failed, record APPROVED, publish).
• Issue and release: the issue's Release field says which version it ships in (the main release), normally from its own project; when the fix ships only in another project (the platform deploy, for example), the main one can be that project's release; the board card and the issue show, for example, "Ships in 2.4.0 · testing". When the same fix ships in more than one place (backend deploy, the OTA of each runtime, console), the other releases go in "Also ships in", from any project in the company. The issue shows up in all of them: in the release's list, the gate, the release notes and the validation. The technical notes' "Fixed version" is just the dev's note about the build with the fix.
• Test case: a script with steps and expected result, reused in every version. Test cycle: one round of tests of a release; each case gets pass, fail or blocked, and a FAIL can open an issue already filled in.
• Release Gate: QA's decision to release (APPROVED) or hold (BLOCKED) the version. The app suggests APPROVED when there's a test cycle with cases, all tests passed and there's no open S1 issue; an open S2 only raises a warning.