Project

General

Profile

Actions
History

Release Management Process (Mandatory)

Applies to all Tinggit products managed in Redmine
Defines how customer-facing value is planned, delivered, tracked, and audited

1. Purpose

The Release Management Process defines how Tinggit:

  • Packages completed work into customer-visible releases
  • Preserves a clean, auditable release history
  • Separates business value from deployment mechanics
  • Handles partial releases, hotfixes, and rollbacks safely
  • Produces accurate and trustworthy release notes

This process ensures that every release can be explained, audited, and traced long after deployment.

2. Scope

This process applies to:

  • All Tinggit products and websites
  • All customer-facing releases
  • All issues assigned to a Release Version
  • All teams contributing to a release (Product, Engineering, QA, DevOps)

3. Ownership & Roles

*. Role *. Responsibility
Product Owner Defines release scope, approves readiness, owns release notes
Engineering Ensures implementation is complete
QA Validates quality and acceptance
DevOps Deploys and provides deployment traceability
Scrum Master Ensures process compliance (where applicable)

4. What a Release Is (and Is Not)

4.1 Release Definition

A Release represents:

  • Business value delivered to customers
  • A contractual or communicable product increment
  • A permanent historical record

4.2 What a Release Is NOT

A Release is NOT:

  • A sprint
  • A deployment pipeline
  • A build number
  • A service or UI version
  • A rollback or retry of the same event

bq. A release answers “What value did customers receive?”
It does NOT answer “How was it deployed?”

5. Release Versions in Redmine

Release management uses Redmine Versions.

Element Purpose
Release Version Defines the scope of a product release
Release Notes Customer-facing summary
Deployment Reference Traceability to CI/CD

Rules:

  • Release Versions are permanent
  • Release Versions are never reused
  • Only completed and deployed work belongs to a Release Version
  • Sprint Versions and Release Versions must never coexist on the same issue

6. Release Naming Standards (Mandatory)

Release naming must follow:

Release X.Y – Short Theme
Release X.Y.Z – Hotfix

Examples:

Release 2.5 – Career Expansion
Release 2.5.1 – Hotfix
Release 2.6 – Platform Reliability

Forbidden:

Release Final
Release Test
v2-final-final

7. Release Planning

7.1 Identifying Release Candidates

Release candidates come from:

  • Completed sprint work
  • Approved backlog items
  • Compliance or contractual commitments
Only items that are:
  • Fully implemented
  • QA verified
  • Accepted by Product Owner
    may be considered for release.

7.2 Assigning Release Version

For each accepted issue:

*. Field *. Action
Fixed version Set to Release X.Y

This assignment defines official release scope.

Issues without a Release Version are not part of the release, even if deployed.

8. Release Readiness Validation

Before deployment, the following must be true:

  • All issues in Release Version are Done or Closed
  • No open blockers remain
  • QA sign-off is confirmed
  • Release notes draft is prepared

Saved query used:
Release – NOT Ready (Blockers)

If this query is not empty, release must not proceed.

9. Deployment & Traceability

Deployment execution happens outside Redmine.

After deployment:

  • DevOps provides: * CI/CD pipeline link * Deployment reference URL
  • Product Owner ensures: * Deployment reference is added to release issues * Release Version reflects deployed scope only

bq. Redmine references deployment truth — it never owns it.

10. Release Notes (Customer-Facing)

Release notes are derived from Redmine issues.

They must include:

  • Release name and date
  • Highlights (top value delivered)
  • Features (Stories)
  • Bug fixes
  • Known limitations (if any)

They must NOT include:

  • Commit hashes
  • Service or UI versions
  • Infrastructure details (unless user-impacting)

Release notes are owned by the Product Owner.

11. Release Close Process

Once deployment and communication are complete:

  • Release Version status is set to Closed
  • Stakeholders are notified
  • Post-release bugs are logged separately
Detailed checklist:

12. Partial Releases

Scenario

Some planned items are ready, others are delayed.

Correct Handling

  • Release Version includes only: * Accepted * Deployed items
  • Delayed items: * Do NOT receive the Release Version * Remain in backlog or future sprint
This ensures:
  • Honest release notes
  • No ambiguity about delivered value

13. Hotfix Releases

Hotfixes are handled as separate patch releases.

Rules:

  • No Sprint Version is used
  • A new Release Version is created:
    Release X.Y.Z – Hotfix
Issues are:
  • Tracked independently
  • Deployed immediately
  • Closed after deployment
Detailed handling:

14. Rollback Releases

Rollbacks do not modify history.

Correct handling:

  • Do NOT reopen completed issues
  • Create new Bug issues
  • Assign a new Release Version:
    Release X.Y.Z – Rollback Fix

Rollback is recorded as a new event, not a rewrite.

15. Metrics & Auditability

Release-level audit questions that must always be answerable:

  • What was released?
  • When was it released?
  • Why was it released?
  • What issues were included?
  • Where is the deployment evidence?

These answers are derived from:

  • Release Version
  • Issue history
  • Deployment reference links
  • Release notes

16. Common Mistakes to Avoid

  • Using Sprint Versions as releases
  • Reusing release versions
  • Including incomplete work in a release
  • Editing release scope after closure
  • Treating deployment retries as releases

17. Governance Rules (Non-Negotiable)

  • Every release must have a Release Version
  • Every release must have deployment traceability
  • Every release must be closed explicitly
  • No release history may be rewritten
  • Exceptions must be documented

Violations must be escalated to Product Leadership.

18. Final Statement

The Release Management Process ensures that Tinggit can:

  • Communicate value clearly to customers
  • Maintain long-term trust in metrics
  • Pass internal and external audits
  • Handle emergencies without chaos
  • Scale product delivery responsibly

This process is mandatory for all releases.

Updated by Redmine Admin about 2 months ago · 1 revisions