Skip to content

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

ModeMeaning
DisabledNo approval required. Stages proceed automatically.
All Instance SPOCsEvery SPOC of every instance in the stage must approve.
Any Instance SPOCOne 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.