Appearance
Release Configuration
Release Configuration is the global configuration for how releases behave on this platform. There is one config — everything on this page applies to every release.
Layout
Top to bottom: Product Version, Managed Services, Pipeline Stages, Approval Settings, SLA Thresholds, Escalation POC. A persistent header shows count badges (stages, services) and Save / Reset buttons.
If your edits include validation errors, an alert lists them above the sections and Save is disabled until they are fixed.
Product Version
Current Version is a text input (e.g. 25.3.6).
The product version advances automatically when a Feature or Hotfix release is created (semver bump). Edit here only to correct a mistake or initialise.
Managed Services
The services the pipeline operates on. Anything not listed here is ignored by releases.
- Type a service name in the input and click Add Service (or press Enter).
- Services appear as removable badge chips.
- Services are resolved by Kubernetes labels first, falling back to deployment name.
Pipeline Stages
The ordered sequence of stages.
Each row has:
- Environment dropdown — predefined values (DEV, QA, UAT, STAGING, DEMO, PRE_PROD, PROD) plus any custom values already in use.
- Stage Order number input — stages with the same order run in parallel.
- Delete button.
Click Add Stage to add a row.
Validation: no empty environments, no negative stage orders, no duplicates (same environment + same stage order).
Approval Settings
Approval mode
| Mode | Meaning |
|---|---|
| Disabled | No approval required. Stages proceed automatically. |
| All Instance SPOCs | Every SPOC of every instance in the stage must approve. |
| Any Instance SPOC | One SPOC approval is enough. |
SPOCs are configured per instance — see the SPOCs tab on the Instance detail page.
DevOps trigger
A separate checkbox: Require DevOps trigger after SPOC approval. When on, an explicit human trigger is needed after SPOC approval before deployment actually starts. This is a second gate, not a replacement for approval.
SLA Thresholds
Two columns: normal releases (feature / config) and hotfix releases. Each column has three inputs.
Normal releases (days)
- Reminder — when to nudge waiting approvers.
- Escalation — when to involve escalation contacts.
- Stalled — when to mark the release as stalled.
Hotfix releases (hours)
Same three thresholds, but in hours — hotfixes are time-critical.
Escalation POC
The list of contacts who get involved when a release breaches its SLA thresholds.
- Add User dropdown searches active users.
- Add User button adds to the table.
- The table shows User, Email, IDP User ID with a delete button per row.
If no contacts are configured, the table shows a placeholder message — but a release that breaches SLA with no escalation contacts will simply not page anyone.
Saving
- Save Configuration — disabled unless there are validation-free changes.
- Reset — discards your unsaved edits and reverts to the server state. Enabled only when there are unsaved edits.
There is no inline / per-row save. All sections share one Save button.
When configuration changes take effect
- Stages, services, approval, triggers, SLAs — apply to releases created after the save. Existing in-flight releases continue under the configuration they started with.
- Product version — takes effect on the next release.
- Escalation contacts — apply to alerts emitted after the save.
Tips
- Treat the pipeline like infrastructure. Sketch it first, then build.
- Parallel stages (same Stage Order) save wall time but multiply blast radius. For PROD, run sequentially.
- Approval and trigger gates are cheap to add and slow to add later — turn them on for any stage that can break a customer.
- Hotfix SLA thresholds in hours, normal in days. Do not paste the same numbers into both.

