Ticket lifecycle¶
Every change to the platform is tracked by a Jira ticket in the PPL project on percihealth.atlassian.net. This page describes the statuses a ticket moves through, what each means, and who moves it between them.
One ticket per change
No code lands without a PPL ticket. The ticket key drives the branch name and PR title (see PR reviews) and links the work back to its rationale.
Most tickets originate from the Delivery stage of the product process (DPPD) — a Plan becomes epics and tickets that then move through the statuses below.
Flow¶
flowchart TD
planning["Ready for Planning"] -->|Engineer| open["Open"]
open -->|Product| readydev["Ready for Dev"]
readydev -->|Engineer| indev["In Dev"]
indev -->|Engineer| readyreview["Ready for Review"]
readyreview -->|Engineer| readytest["Ready for Testing"]
readytest -->|QA| intest["In Testing"]
intest -->|QA| readymerge["Ready to Merge"]
readymerge -->|"Engineer ⭐"| staging["On Staging"]
staging -->|QA| readyrelease["Ready for Release"]
readyrelease -->|"Release manager ⭐"| done["Done"]
open -.-> blocked["Blocked"]
readydev -.-> blocked
indev -.-> blocked
readytest -.-> blocked
intest -.-> blocked
blocked -.->|unblocked, back to original status| open
classDef auto fill:#fff3cd,stroke:#e0a800,color:#000;
class readymerge,readyrelease auto;⭐ = transitions we want to automate with Jira automation (see Automation).
Statuses¶
| Status | Meaning | Moved on by |
|---|---|---|
| Ready for Planning | Initial status when a ticket is created. Details and requirements are specified. | Engineer |
| Open | Ticket is reviewed and technical requirements are specified. | Product |
| Ready for Dev | The task now has all the information required for implementation. | Engineer |
| In Dev | Being worked on by the engineer. The engineer creates a branch in the relevant project, e.g. PPL-121/change-auth. |
Engineer |
| Ready for Review | The work is ready for code review by another member of the team. | Engineer |
| Ready for Testing | Development is complete; changes are ready for testing in the branch. | QA |
| In Testing | Changes are tested locally in the development branch. | QA |
| Ready to Merge | Changes have been verified and are merged into develop. |
Engineer ⭐ |
| On Staging | Regression tests are executed. | QA |
| Ready for Release | Regression tests pass; ready for release. | Release manager ⭐ |
| Done | Changes have been deployed to production. | — |
The branch naming (PPL-NNNN/...) and merge-into-develop step line up with
PR reviews and Branching & releases.
Assign a fix version before staging
A fix version must be assigned before a ticket moves from Ready to Merge to
On Staging. This is what ties the change to a release; releases are cut from
develop (see Branching & releases).
Blocked¶
Any in-flight status (Open through In Testing) can move to Blocked when work can't proceed. When unblocked, the ticket returns to the status it was in before it was blocked.
Automation¶
The two ⭐ transitions are targets for Jira automation, to remove manual status-dragging and keep Jira in sync with what GitHub and the deploy pipeline already know:
| # | Transition | Proposed trigger | Notes |
|---|---|---|---|
| ⭐1 | Ready to Merge → On Staging | PR for the ticket is merged into develop. |
Should also enforce/auto-assign the fix version (see warning above) so nothing reaches staging without one. |
| ⭐2 | Ready for Release → Done | Change is deployed to production (release merged to main). |
Currently done manually by the release manager (Celina). |
CONFIRM — automation triggers
Confirm the exact trigger wiring before building these: which GitHub event fires ⭐1
(PR merged vs deployment), and what signals "deployed to prod" for ⭐2 (the
release/* → main merge, a successful deploy workflow, or a GitHub Release). Smart
Commits / the Jira GitHub integration can drive transitions from commit and PR events.