Jira And OPS Workflow Management

This document defines one combined workflow for Jira tracking, testing, release readiness, deployment, production verification, rollback, incident handling, and hotfix operations.

Jira is the source of truth for work packages, statuses, role ownership, required fields, evidence, and final acceptance. OPS activities are part of the same workflow through release, production, rollback, incident, and hotfix statuses or responsibilities.

See ST Git Convention for Git branching, commit conventions, PR rules, merge strategy, release composition mechanics, and detailed hotfix Git mechanics.

Document boundary:

• [ST] Git Convention.md defines how source changes move through Git.
• This SOP defines who acts, when they act, and what approval, evidence, readiness, release, deployment, and recovery decisions are required.

1. Board Statuses And Workflow

The standard workflow uses only three required deployment/testing environments: DEV, UAT, and PROD. DEV is the integration/testing environment for internal verification, UAT is the release acceptance environment, and PROD is Production. Projects MAY add optional verification gates such as SIT, QA, Demo, Staging, or Preprod when required by the project. Optional gates are verification checkpoints and do not imply that a corresponding permanent Git branch exists.

Ready For Prod at ticket/work-package level means the work package has passed its required ticket-level verification and is eligible to be considered for release selection. It MUST NOT mean that the ticket independently authorizes a Production deployment.

Ticket Ready For Prod
        |
        v
Eligible for release selection

Release Ready For Production
        |
        v
Exact release candidate + exact immutable artifact
        |
        +-- dependency closure verified
        +-- required CI passed
        +-- release-level UAT passed
        +-- UAT approval matches artifact
        +-- Production baseline verified
        +-- DB migration compatibility verified
        +-- rollback / roll-forward ready
        |
        v
Production deployment authorized

1.1 Status Ownership By Role

Each status SHOULD have a clear owner. The owner is responsible for keeping Jira accurate, attaching evidence, and moving the ticket to the next valid status.

1.2 Mandatory Jira Fields By Role

Each role MUST update the required Jira fields before moving a ticket to the next status. A ticket should not move forward when required fields, owner, evidence, or links are missing.

Developer-specific rules:

• Dev MUST assign the ticket to themselves before starting implementation.
• Dev MUST fill Start Date and Dev ETA Date when moving the ticket to In Progress.
• Dev MUST confirm the ticket has a project-defined Story Point Estimate and Estimate Boundary before starting, except urgent production incidents.
• Dev MUST create a branch that includes the Jira ticket ID.
• Dev MUST keep Jira updated when scope, ETA, blockers, or implementation direction changes.
• Dev MUST attach self-test evidence before moving the ticket to In Review.
• Dev MUST include the PR link in Jira before requesting review.
• Dev MUST document migration, environment variable, deployment, rollback, or data-impact notes when applicable.
• Dev MUST NOT move a ticket to Ready For Testing by themselves unless the project explicitly allows developer-owned review approval.
• Dev MUST NOT move a parent Story, Task, or Epic forward while a required Bug fix is not merged, deployed to the tested environment, and retested by QA.

1.3 Role-Based Flow

Use this flow to determine who acts next:

1. Reporter / PO / BA: create or refine the ticket in To Do
2. Developer / Assignee: move to In Progress when implementation starts, assign themselves, fill Start Date and Dev ETA Date
3. Developer / Assignee: implement, self-test, attach evidence, open PR, then move to In Review
4. Reviewer / Tech Lead: approve and move to Ready For Testing, or request changes and move back to In Progress
5. QA / Tester: move to In Testing, execute internal tests, then move to System Test when system-level validation is required
6. Optional Gate Owner: verify configured optional gates such as SIT, QA, Demo, Staging, or Preprod when the project requires them
7. Customer / UAT Owner: verify in UAT and move to Ready For Prod when accepted
8. Release Owner / OPS: move to Prod, deploy, verify production, then move to Done after successful production verification
9. Any role: move to Blocked when work cannot continue, document the blocker, and assign the responsible unblocker

When a stage fails, the owner of that stage MUST follow the Bug Flow in this document. The original ticket stays in the failed testing status unless the bug blocks all remaining work; in that case, move the original ticket to Blocked and link the blocking Bug.

1.4 Status Flow Rules

Use this table as the operating rule for each Jira status. A ticket should move forward only when the current status owner has completed the required action and attached the required evidence.

General status rules:

• A ready status means the previous owner has finished their work and the next owner can start.
• An active status means the current owner is doing work or verification now.
• A parent Story, Task, or Epic should not pass the current testing status while blocking or critical Bugs are still open.
• The standard required environment path is DEV -> UAT -> PROD.
• Optional gates such as SIT, QA, Demo, Staging, or Preprod MAY be inserted after DEV verification only when the project requires them.
• Every status transition should have a Jira comment when the reason is not obvious from the PR, test evidence, or release ticket.

2. Work Package Types

A work package is any Jira item used to plan, implement, verify, or release work. The type should match the size and purpose of the work.

2.1 Story vs Task

Use a Story when the work describes user or business value:

As an operator, I want to view pond water trends so that I can detect abnormal conditions early.

Use a Task when the work is implementation-focused:

Create database indexes for pond sensor readings.

If a Story needs multiple implementation pieces, create Sub-tasks or linked Tasks under the Story.

2.2 Story Point Estimation

Story points measure the relative effort, risk, and uncertainty needed to complete a work package. The main purpose is to estimate whether a Story, Task, Bug, or Epic slice can be completed within the planned sprint, release, or delivery window.

Each team or project may define its own point scale after calibration. Fibonacci is the recommended default because it avoids false precision for larger or riskier work.

Story points can be converted into a planning ratio such as points per hour or hours per point, but that ratio is team-specific. It should be calculated only after the team has completed enough real work to establish a stable baseline.

Every project MUST define the Estimate Boundary before using story points. The boundary answers: "How far does this point estimate cover?"

Default rule: use Delivery Story Point unless the project explicitly documents another boundary. If the team says "Dev estimate", it usually means Dev-Only Point, not the full delivery point.

Delivery Story Point vs Dev-Only Point

These two estimates answer different planning questions and MUST NOT be treated as the same number.

Practical examples:

• If a ticket is estimated as Delivery Story Point, the point should cover the work needed for the parent Story/Task/Epic to pass its required workflow, including bug fixes found by QA/System Test when they are part of getting that ticket accepted.
• If a ticket is estimated as Dev-Only Point, the point stops at Dev handoff. QA/System Test/UAT/OPS work must be estimated separately, or the team must not use that number as full delivery velocity.
• A Dev-only estimate can be lower than the Delivery Story Point for the same ticket because it excludes QA, acceptance, release, and cross-role support.
• Sprint velocity should use Delivery Story Points by default. If the team uses Dev-only velocity, the report name must say so clearly.

Recommended default Fibonacci values:

0, 1, 2, 3, 5, 8, 13, 21

Story point rules:

• A Story, Task, or Bug MUST have a story point estimate before moving to In Progress, except urgent production incidents.
• Each project MUST define one agreed point scale for the team. Fibonacci is the recommended default scale.
• Each project MUST define whether story points are Delivery Story Points, Dev-Only Points, or Environment-Bound Points.
• Do not mix different estimate boundaries in the same sprint, board, or velocity report.
• Delivery planning SHOULD use Delivery Story Points because it represents complete task delivery.
• Dev capacity planning may use Dev-Only Points, but the team MUST label it clearly as Dev-only.
• If the project uses Fibonacci, do not use 4, 6, 7, 10, or raw hour values as story points.
• Estimate the whole delivery effort, including coding, review, testing support, bug-fix risk, migration, and deployment coordination when applicable.
• Increase the estimate when requirements are unclear, dependencies are risky, or the change touches shared behavior.
• If a ticket is estimated at 13 or 21, the team SHOULD split it before implementation.
• If scope changes during implementation, Dev MUST comment in Jira and ask PO / BA / Tech Lead whether the story point estimate should be updated.
• Sub-tasks may have story points only when the project uses sub-task estimation. Otherwise, estimate the parent Story or Task.
• Bugs found during QA/System Test may be estimated separately when the fix requires meaningful Dev effort.

Team calibration:

Calibration rules:

• The team SHOULD NOT lock a fixed hour-per-point ratio before there is enough delivery history.
• Use at least 2-3 completed sprints before treating the ratio as a planning baseline.
• Calculate the ratio from completed work only. Do not include unfinished tickets, carried-over tickets, or tickets that were not accepted.
• Recalibrate when team size, seniority, project complexity, tools, or Definition of Done changes.
• Use the calibrated ratio for capacity planning, not for pressuring individual developers.
• Different teams may have different point/hour ratios even when using the same point scale.
• Story points should still be decided by complexity, risk, dependencies, and uncertainty. The point/hour ratio is a forecasting tool after the team has real data.

2.3 Epic Rules

An Epic SHOULD have:

• Clear business or technical outcome
• Linked Stories, Tasks, Bugs, or Spikes
• Defined owner
• Target release or milestone, when known
• Exit criteria for closing the Epic

An Epic MUST NOT be closed until all required child work packages are complete or explicitly descoped.

2.4 Bug Rules

A Bug ticket MUST include:

• Expected Result
• Actual Result
• Steps to reproduce
• Environment where the bug was found
• Build version, commit SHA, branch, or deployment artifact when available
• Evidence such as video, screenshots, logs, request IDs, or test data
• Severity or priority
• Linked parent Story, Task, or Epic, when applicable
• Clear assignee or responsible owner

A Bug ticket MUST be linked to the parent work package when it is found during testing of a Story, Task, Epic, or release scope. The parent ticket should not move forward while it still has open blocking or critical Bugs.

3. Testing Terms

Different projects may use different testing gates. The definitions below keep the language consistent across Jira, PRs, and release notes.

3.1 What Is System Test?

System Test validates that the whole application or system satisfies the expected behavior from the user's point of view.

It is broader than unit or integration testing. A System Test may include UI, API, database, background jobs, permissions, notifications, reports, and external integrations when they are part of the requirement.

System Test SHOULD answer:

• Does the complete feature work end-to-end?
• Does it satisfy the acceptance criteria?
• Does it work with realistic data and roles?
• Does it avoid regressions in related user flows?
• Are errors, empty states, and permissions handled correctly?

System Test is not always the same as SIT:

• System Test checks the complete product behavior for a requirement.
• SIT checks whether multiple systems or services integrate correctly.

3.2 System Test Flow

Use System Test when QA is testing the complete behavior of a parent Story, Task, or Epic from the user's point of view.

System Test is an active testing status. It is not a "ready" status. If QA finds a defect during System Test, QA creates or links a Bug ticket. Dev fixes that Bug, QA retests it, and the parent Story, Task, or Epic can pass System Test only after the required Bugs are resolved.

Before starting System Test, the QA / Tester MUST confirm:

• The parent ticket is in System Test
• The correct branch, build, deployment, or environment is available
• Acceptance criteria and expected behavior are clear
• Required test data, accounts, permissions, and external dependencies are ready
• Known open Bugs are reviewed before testing starts

During System Test, the QA / Tester SHOULD cover:

• Main successful user flow
• Negative or validation scenarios
• Permission and role-based scenarios
• Empty, error, and edge states
• Related regression areas
• Data persistence, background jobs, notifications, reports, or integrations when they are part of the requirement

After System Test:

• If System Test passes, attach evidence and move the ticket to the next configured gate. The standard path moves to Ready For UAT or Ready For Prod; optional configured gates may include Ready For SIT, Ready For QA, or Ready For Staging
• If QA finds a defect, create or link a Bug ticket and follow the Bug Flow below
• If the failure blocks all meaningful testing, move the parent ticket to Blocked and link the blocking Bug
• If the failure is not blocking, keep the parent ticket in System Test until the Bug is fixed or explicitly accepted as a known issue by the PO / BA, QA Owner, and Release Owner
• If the Bug retest passes and no blocking or critical Bugs remain, continue System Test and move the parent ticket forward only when the parent acceptance criteria pass

System Test evidence MUST include the tested scenarios and at least one reviewable artifact, such as a video, screenshots, logs, request IDs, test case result, or test data reference.

3.3 Bug Flow

A Bug means the actual result does not match the expected result. In this workflow, a Bug is usually created by QA while testing a parent Story, Task, or Epic. The Bug represents the fix work Dev must complete so the parent ticket can pass testing.

A Bug can be found during internal testing, System Test, SIT, QA, Staging, UAT, Prod smoke test, or production operation.

When a Bug is found during testing:

1. Create a new Bug ticket or link an existing Bug ticket
2. Link the Bug to the parent Story, Task, Epic, release ticket, or incident
3. Fill Expected Result, Actual Result, Steps to Reproduce, Environment, Severity, and evidence
4. Assign the Bug to the original implementer or the responsible owner
5. Keep the parent ticket in the failed test status, such as In Testing, System Test, SIT, QA, Staging, or UAT
6. Move the parent ticket to Blocked only when the Bug prevents all remaining testing or release activity
7. Developer fixes the Bug using the correct Git flow from ST Git Convention
8. Developer opens or updates the PR, self-tests the fix, and moves the Bug to In Review
9. Reviewer approves the Bug fix and moves the Bug to Ready For Testing
10. QA retests the Bug in the same environment where it failed, or in the agreed target environment
11. If retest passes, attach retest evidence, move the Bug to Done, and continue testing the parent ticket
12. If retest fails, move the Bug back to In Progress, add the new actual result and evidence, and repeat the fix/retest loop

The parent Story, Task, or Epic is allowed to pass only after the Bug fix is merged/deployed to the tested environment and QA confirms the retest result.

A Bug ticket normally uses this status flow:

Blocked -> To Do -> In Progress -> In Review -> Ready For Testing -> In Testing or System Test -> Done

Any Bug status -> Blocked -> return to previous valid status after unblocked

Bug severity SHOULD be interpreted as:

• Blocker: prevents release, deployment, or all meaningful testing
• Critical: breaks a core flow, causes data loss, security risk, or major business impact
• Major: breaks an important flow but has a reasonable workaround
• Minor: small functional issue with limited impact
• Trivial: typo, cosmetic issue, or low-risk polish item

A parent ticket may move forward only when all blocking and critical Bugs are fixed, retested, and linked evidence is available. Non-blocking Bugs may remain open only when the PO / BA, QA Owner, and Release Owner explicitly accept them as known issues.

4. Task Management Workflow

4.1 Create Task

Owner: Reporter / PO / BA

When a new requirement is confirmed, create a Jira task in To Do.

The task creator MUST provide a clear description, including:

• Task objective
• Acceptance criteria
• Estimated effort or story points
• Relevant design, API, data, or business notes
• Dependencies, if any

Keep the task in To Do until it has enough information for a developer to start without major clarification.

4.2 Start Implementation

Owner: Developer / Assignee

When a developer starts work:

1. Move the task from To Do to In Progress
2. Assign the task to themselves
3. Fill in Start Date
4. Fill in Dev ETA Date
5. Create the Git branch using the Jira ticket ID

Example:

feat/PROJ-123-google-login
fix/PROJ-245-payment-timeout

4.3 Code Review

Owner: Reviewer / Tech Lead

When coding is complete:

1. Open a PR according to ST Git Convention
2. Move the task to In Review
3. Attach or link a self-test video in the Jira task
4. Comment with the tested scenarios
5. Mention the team lead or reviewer

After the reviewer approves the PR, the reviewer or ticket owner MUST move the ticket to Ready For Testing. If changes are requested, move the ticket back to In Progress and assign it to the developer.

4.4 Internal Testing

Owner: QA / Tester

Before testing starts:

1. Assign the Tester field
2. Move the ticket to In Testing
3. Confirm the test scope, acceptance criteria, and test cases
4. Confirm the tested branch, build, deployment, or environment

After testing:

• If initial internal testing passes and System Test is required, move the ticket to System Test and follow the System Test Flow
• If System Test is not used, move the ticket to the next configured gate. The standard path moves to Ready For UAT; optional configured gates may include Ready For SIT, Ready For QA, or Ready For Staging
• If testing fails at any point, create or link a Bug ticket and follow the Bug Flow
• Attach testing evidence before moving the ticket forward

The ticket MUST NOT move forward while a blocking or critical Bug remains open.

4.5 Optional Environment Gates

Owner: SIT Owner, QA Owner, Staging Owner, Release QA, or the configured environment owner

The standard required environment path remains DEV -> UAT -> PROD.

Projects may use additional optional verification gates such as SIT, QA, Demo, Staging, or Preprod. These gates are optional checkpoints, not mandatory environments and not required Git branches.

For each configured environment:

1. Move the ticket to the matching ready status, such as Ready For SIT or Ready For Staging
2. Assign the responsible tester or verifier
3. Move the ticket into the active environment status when verification starts
4. Attach test evidence after verification
5. If verification passes, move the ticket to the next configured gate
6. If verification fails, create or link a Bug ticket and follow the Bug Flow

4.6 User Acceptance Testing

Owner: Customer / UAT Owner

When internal testing passes, move the task to Ready For UAT.

When customers or users begin acceptance testing, move the task to UAT.

If UAT passes, move the task to Ready For Prod when production release is required. If production release is not required for the task, move it to Done.

If UAT fails, create or link a Bug ticket and follow the Bug Flow. The parent ticket should stay in UAT unless the failure blocks all UAT activity; in that case, move it to Blocked and link the blocking Bug.

Ticket-level UAT confirms acceptance of an individual work package. It does not prove that a selected combination of multiple work packages is safe for Production.

Final release-level UAT MUST validate the exact complete release candidate intended for Production. Production approval MUST be bound to the exact release source state and immutable artifact tested in final release-level UAT.

4.7 Production Release And Verification

Owner: Release Owner / OPS

When all required verification passes:

1. Move the task to Ready For Prod
2. Confirm whether the task is part of a normal selective release or an explicitly approved single-ticket release
3. Confirm release scope, release metadata, artifact identity, deployment owner, and rollback/roll-forward plan
4. Move the task to Prod when production deployment starts
5. Attach production deployment or smoke-test evidence
6. Move the task to Done only after production verification passes or when the project explicitly tracks Production completion on a separate release ticket

For normal Production releases, follow the Release Selection, Release Manifest, Deployment Readiness, and Production Release sections below.

4.8 Complete Task

Owner: Reporter / PO / BA, with confirmation from Release Owner / OPS when production release was required

A task may move to Done only when all required acceptance and verification steps are complete.

Do not close a task manually if code review, internal testing, optional SIT/QA/Staging gates, UAT, Prod deployment, or required release verification is still pending.

5. Workflow Rules

• Always keep the Jira status accurate.
• Required Jira fields MUST be filled by the responsible role before moving a ticket forward.
• Story, Task, and non-trivial Bug tickets MUST have a project-defined story point estimate before moving to In Progress.
• The project MUST define the story point Estimate Boundary before using story points for planning.
• If a task is blocked, move it to Blocked and document the blocker.
• A blocked task MUST identify the person or team responsible for resolving the blocker.
• Move a task forward only after the Definition of Done for that stage is satisfied.
• Do not close a task before it passes all required review and testing stages.
• Every meaningful comment, decision, blocker, or test result SHOULD be recorded in Jira.

6. Definition Of Done

A task is considered complete only when:

• Code is complete
• Code review is approved
• Required CI checks pass
• Internal testing has no critical or blocking bugs
• System Test passes, when System Test is required
• Optional gates such as SIT, QA, Staging, Preprod, or other configured environment gates pass, when required
• UAT passes, when UAT is required
• Production deployment and smoke testing pass, when production release is required
• Documentation is updated, when needed
• Migration, deployment, and rollback notes are documented, when applicable
• Jira contains sufficient evidence for review, testing, or release audit

7. Notes

• A task MUST have a clear description, acceptance criteria, and effort estimate before implementation starts.
• When blocked, update Jira immediately and notify the team lead.
• Do not move a task to Done before it has passed the required workflow stages.
• Testing evidence should be easy for the team lead, QA, or customer to review.
• Production-impacting work should include release notes and a rollback plan.

8. Field Definitions

9. Jira And Git Traceability

Every branch, commit, and PR SHOULD be traceable to a Jira issue.

Branch names SHOULD include the ticket ID:

feat/PROJ-123-google-login
fix/PROJ-245-payment-timeout
hotfix/PROJ-900-payment-crash

Commit footers SHOULD include Refs: for related work:

Refs: PROJ-123

Use Closes: only when merging the PR should close the Jira issue:

Closes: PROJ-123

PR descriptions SHOULD include:

• Jira ticket link
• Jira status
• Summary of change
• Verification completed
• Target environments
• Screenshots or evidence for UI changes
• Deployment, migration, rollback, or OPS notes

10. Release And OPS Responsibilities

OPS work starts when a verified scope needs release selection, configured environment verification, production release, rollback, incident handling, or hotfix coordination.

Environments are deployment/testing destinations and approval gates. The SOP MUST NOT imply a Git promotion chain such as dev -> sit -> staging -> uat -> main.

The following OPS information MUST be recorded before Production deployment:

• Release scope and included Jira tickets
• Intentionally excluded work when useful for audit clarity
• Intended Production base branch and base commit
• Deployment owner and verifier
• Immutable artifact identity
• Migration and configuration impact
• Rollback or roll-forward strategy
• Monitoring/logging checks
• Open Bugs and accepted known issues

After Production deployment, the following MUST be recorded:

• Final deployment result
• Production verification result
• Deployed immutable artifact identity

11. Release Selection

Owner: Release Owner

dev is an integration/testing state only. It MAY contain ready and unfinished work at the same time, and MUST NOT automatically define the next Production release.

The Release Owner MUST:

1. Identify Jira issues ready for release.
2. Select only approved work for the target release.
3. Explicitly exclude incomplete or unapproved work.
4. Verify mandatory dependency closure.
5. Confirm required DB migrations.
6. Record the intended Production baseline.
7. Create or update auditable release metadata / Release Manifest.
8. Coordinate creation of release/<version> according to ST Git Convention.

Normal selective Production releases MUST use release/<version> created from the intended Production baseline and composed only from selected approved work, mandatory dependency closure, required DB migrations, and approved release fixes.

Release composition should use selected working branches according to ST Git Convention. Cherry-pick MAY be used when intentionally selecting specific commits, but MUST NOT be presented as the mandatory or default release mechanism.

Example:

DEV integration state:

A = READY       -> include
B = NOT READY   -> exclude
C = READY       -> include
D = NOT READY   -> exclude

Release 1.5.0 = A + C + mandatory dependencies

If tickets A and C are Ready For Prod, they are eligible for release selection. They do not have to be deployed immediately, they do not have to belong to the same release, and DEV does not become the Production candidate. The resulting selected release candidate MUST still pass release-level validation before Production.

12. Release Manifest / Auditable Release Metadata

Every normal Production release MUST have auditable release metadata.

The Release Manifest MUST identify at least:

• Release version
• Release Owner
• Intended Production base branch
• Intended Production base commit
• Included Jira tickets
• Intentionally excluded work when useful for audit clarity
• Dependency closure
• DB migrations when applicable
• Release commit SHA
• Immutable artifact ID/version/digest
• UAT result
• Exact UAT-approved artifact
• Production baseline checked before promotion
• Rollback strategy
• Roll-forward strategy when applicable
• Accepted known issues
• Deployment result

A conceptual YAML example MAY be used, but YAML is not mandatory unless the company or project explicitly chooses it as the required format.

13. Release Freeze And UAT Invalidation

Before final release-level UAT:

• Release scope MUST be explicit
• Dependency closure MUST be complete
• Candidate source state MUST be identifiable
• Artifact MUST be immutable and traceable

Final release-level UAT MUST validate the exact complete release candidate intended for Production. Ticket-level UAT confirms acceptance of an individual work package; it does not automatically prove that a combined A+C release candidate is Production-ready.

Any source, dependency, migration, or runtime-affecting configuration change to an approved release candidate MUST invalidate the previous release-level UAT approval.

A new immutable artifact MUST be built and the required release-level UAT validation MUST be performed again.

artifact X
   |
   v
UAT approved
   |
candidate changes
   |
   v
approval INVALID
   |
   v
build artifact Y
   |
   v
required UAT again

14. Deployment Readiness

Before Production deployment, the release ticket or Release Manifest MUST confirm:

• Release Manifest complete
• Release scope verified
• Included Jira issues verified
• Dependency closure verified
• Required PRs merged
• Required CI checks passed
• Release commit SHA verified
• Immutable artifact identity verified
• UAT approval matches exact artifact identity
• Production baseline compatibility checked
• Required testing gates passed
• DB migration compatibility reviewed
• Configuration and secrets ready
• Feature flags configured where applicable
• Rollback or roll-forward strategy ready
• Release Owner identified
• Deployment owner/verifier identified
• Monitoring/logging checks known
• Open Bugs / accepted known issues recorded

Production deployment MUST NOT start while a mandatory readiness condition is unresolved.

15. Production Release

Normal Production flow:

release/<version>
      |
      v
CI
      |
      v
Build immutable artifact X
      |
      v
Final release-level UAT
      |
      v
Approve artifact X
      |
      v
Production readiness verification
      |
      v
merge release/<version> -> main
      |
      v
tag release
      |
      v
promote SAME artifact X
      |
      v
Production

Production MUST promote the exact immutable artifact approved in UAT.

The normal Production release flow MUST NOT rebuild a different artifact from main after final UAT approval.

The merge to main records the approved release source state; it does not authorize replacing the UAT-approved artifact with a new build.

After deployment, OPS / Release Owner MUST run smoke tests, check logs, metrics, queues, scheduled jobs, and critical user paths, then record the deployment result in Jira or the release channel.

When Production deployment is tracked on the work-package ticket itself, the ticket MAY move to Done only after required Production verification passes.

If the project tracks Production deployment and verification on a separate release ticket, the work-package ticket MAY complete at Ready For Prod according to the project's documented Jira workflow. In that model, the release ticket MUST remain responsible for Production deployment, smoke-test, monitoring, final outcome, and required Production evidence.

16. Database Migration Readiness

When a release contains DB/schema migrations, OPS readiness MUST identify or verify:

• Migration ID
• Affected service/application
• Deployment order
• Backward compatibility
• Compatibility with previous application version where relevant
• Data impact
• Reversibility
• Rollback impact
• Whether rollback is safe
• Roll-forward strategy when rollback is unsafe

Where feasible, migrations SHOULD remain backward-compatible through the deployment and rollback window.

A migration MAY be irreversible. When rollback is unsafe or impossible, Release Owner and Tech Lead MUST define a roll-forward or alternative recovery strategy before deployment.

17. Rollback And Roll-Forward

Every Production release MUST define a recovery strategy before deployment: rollback, roll-forward, or both.

When immutable artifacts exist, application rollback SHOULD use the previously approved artifact rather than rebuilding an old Git revision.

application rollback
!= database rollback
!= external side-effect rollback

If DB or external effects make rollback unsafe, Release Owner and Tech Lead MUST define an alternative recovery/roll-forward strategy before deployment.

18. Concurrent Releases

Multiple release lines MAY be active simultaneously.

Each active release MUST record its Production base commit.

When main advances because of another release or hotfix, the Release Owner MUST evaluate whether each active release is affected.

Active releases MUST NOT automatically merge or rebase the latest main.

Rules:

• Unaffected release -> MAY retain recorded baseline
• Affected release -> synchronize smallest safe required change
• Candidate mutation -> new artifact + required UAT again
• Decision MUST be auditable in release metadata
• Older release MUST NOT silently overwrite newer Production state
• Out-of-order Production promotion requires explicit impact review/exception

19. Incidents And Hotfixes

Incident and Hotfix are not synonymous.

An Incident is a Production-impacting event requiring investigation and coordination. An Incident MAY be resolved through mitigation, configuration change, feature flag, rollback, roll-forward, or hotfix.

A Hotfix is an urgent code change used to resolve a Production problem when a code change is required. A Hotfix MAY be one technical response to an Incident.

If the current Jira configuration uses a combined Hotfix / Incident work-package type, that is an implementation/tracking choice and does not mean Incident and Hotfix are the same operational concept.

For production incidents:

1. Create or link an Incident or Hotfix Jira ticket.
2. Assign Incident Owner and technical owner.
3. Record severity, impact, start time, affected services, and customer impact.
4. Assess rollback, mitigation, roll-forward, or hotfix path.
5. Follow ST Git Convention when a code hotfix is required.
6. Record production verification after mitigation, rollback, roll-forward, or deployment.
7. Evaluate affected active release, integration, and long-lived development lines.
8. Complete post-incident review for high-severity incidents.

19.1 Hotfix Source

A hotfix branch MUST originate from the latest Production baseline on main:

main (latest Production baseline)
        |
        | checkout
        v
hotfix/PROJ-900

Hotfixes MUST NOT originate from dev, a deployment/testing environment, or an arbitrary active release branch during the normal flow.

19.2 Hotfix Flow

Production Incident
        |
        v
Create/link Incident or Hotfix Jira ticket
        |
        v
Assess rollback / mitigation / hotfix
        |
        +---------------- rollback/mitigation ----------------+
        |
        v
latest Production main
        |
        | checkout
        v
hotfix/PROJ-900
        |
        v
implement + test + CI
        |
        v
review / approval
        |
        v
merge -> main
        |
        v
tag
        |
        v
Production
        |
        v
verify fix
        |
        v
evaluate affected active lines

19.3 Hotfix Synchronization

After the hotfix reaches Production, the Release Owner and Tech Lead MUST evaluate active release, integration, and long-lived development lines that could reintroduce the defect.

The hotfix MUST be synchronized only to affected lines.

A hotfix MUST NOT be blindly merged into every active branch.

hotfix -> main -> Production
                 |
                 v
          evaluate impact
          /      |       \
        dev  release/1.6  epic/X
         |       |          |
     affected? affected? affected?
        YES      YES         NO
         |        |           |
        sync     sync       no sync

If hotfix synchronization changes an active release candidate, that release MUST produce a new artifact and repeat required release-level UAT.

Post-incident review SHOULD capture:

• Root cause
• Timeline
• Detection gap
• What worked
• What did not work
• Preventive actions
• Follow-up Jira tickets

20. Production Failure Flow

Production
    |
    v
Smoke Test + Monitoring
    |
    +---- PASS ----> Done
    |
    +---- FAIL
             |
             v
          Incident
          /   |    \
   rollback hotfix roll-forward

Production deployment MUST leave a minimum auditable record.

Production evidence MUST include at least:

• Deployed immutable artifact identity
• Release version
• Production deployment result
• Smoke-test result
• Final Production outcome

When applicable, Production evidence MUST also include:

• Monitoring result
• Incident link
• Rollback record
• Hotfix link
• Roll-forward record

Quick Reference

Jira Task Flow

Blocked -> To Do -> In Progress -> In Review -> Ready For Testing -> In Testing -> System Test -> Ready For UAT -> UAT -> Ready For Prod -> Prod -> Done

Any working/testing/release status -> Blocked -> return to previous valid status after unblocked

Full Environment Flow

Required environment path: DEV -> UAT -> PROD

Main Jira path:
Blocked -> To Do -> In Progress -> In Review -> Ready For Testing -> In Testing/System Test (DEV) -> Ready For UAT -> UAT -> Ready For Prod -> Prod -> Done

Optional gates after DEV verification, when configured:
Ready For SIT -> SIT
Ready For QA -> QA
Ready For Demo -> Demo
Ready For Staging -> Staging
Ready For Preprod -> Preprod

Any working/testing/release status -> Blocked -> return to previous valid status after unblocked

Role Flow

PO/BA -> Developer -> Reviewer/Lead -> QA/Tester -> Optional Gate Owner when configured -> UAT Owner -> Release/OPS -> PO/BA

Status Type Rule

Ready status = waiting for next owner to start
Active status = owner is doing work/testing/release now
Done = accepted and complete
Blocked = cannot continue until blocker is resolved, then return to the previous valid status

Story Point Scale

recommended default: 0, 1, 2, 3, 5, 8, 13, 21
each project/team may define its own scale after calibration
estimate boundary must be defined before planning
Delivery Story Point = covers until Done / required release gate
Dev-Only Point = covers until Ready For Testing or In Testing
Delivery velocity = use Delivery Story Points
Dev capacity = may use Dev-Only Points, clearly labeled
Environment-Bound Point = covers until the agreed gate, such as System Test, optional SIT, UAT, or Prod
points per hour = completed points / actual team delivery hours
hours per point = actual team delivery hours / completed points
calibrate only after 2-3 completed sprints
13 = should split when possible
21 = too large, split or treat as Epic-level planning

Bug During Testing

test failed -> create/link Bug -> link parent -> add Expected/Actual/Steps/Environment/Evidence -> assign owner -> fix -> review -> retest -> close Bug -> continue parent ticket

Bug Ticket Flow

Blocked -> To Do -> In Progress -> In Review -> Ready For Testing -> In Testing/System Test -> Done

Any Bug status -> Blocked -> return to previous valid status after unblocked

System Test Flow

System Test -> pass: next required gate or optional configured gate / defect found: create Bug -> Dev fix -> QA retest -> parent passes only after required Bugs are resolved

OPS Release Flow

Ready Jira Work
      |
      v
Select Release Scope
      |
      v
Dependency Closure
      |
      v
Release Manifest
      |
      v
release/<version>
      |
      v
Freeze Candidate
      |
      v
CI
      |
      v
Build Immutable Artifact X
      |
      v
Final Release-Level UAT
      |
      v
Approve Exact Artifact X
      |
      v
Production Readiness
      |
      v
release/* -> main
      |
      v
Promote SAME Artifact
      |
      v
Production
      |
      v
Smoke Test + Monitor
      |
      +---- PASS -> record Production evidence -> Done
      |
      +---- FAIL -> Incident
                       |
                 +-----+-----+
                 |     |     |
              Rollback Hotfix Roll-forward

Hotfix Quick Reference

Production Incident
      |
      v
Assess response
      |
code fix required
      |
      v
latest main
      |
      v
hotfix/<ticket>
      |
      v
implement -> test -> review
      |
      v
main -> Production
      |
      v
verify
      |
      v
evaluate affected active lines
      |
      v
sync only where required