Docs

Deployments

What this screen is for

Deployments — the Release Manager — is how changes reach production in a way you can account for afterwards. A release groups the components going out together, records what is in it, collects the sign-offs, and drives the runbook that executes it.

If Dev and Staging are where you find out whether a change works, this is where you decide it is going live and leave a record of having done so.

Before you start

To do this You need
Open the area deployment-manager.access
Create a release deployment-manager.release.create
Open a release’s details deployment-manager.release.view.details
Use the quick actions on a release deployment-manager.release.view.details.quick-actions
Sign off a release deployment-manager.release.signoff
Delete a release deployment-manager.release.delete
Delete any release, including others’ deployment-manager.release.admin-delete
Change configuration deployment-manager.config.<area> — one per tab

The configuration permissions are granular on purpose: config.jira, config.environments, config.signoff-roles, config.notifications, config.release-notes-template, config.tag-patterns, config.general. You can let someone manage notifications without letting them change sign-off rules.

Opening it

  1. Deploy › Deployments in the sidebar.

Direct URL: /deployment-manager

The interface

📸 Screenshot Placeholder: The Deployments dashboard. Mark: (1) the releases list, (2) the create action, (3) the link to configuration.

Page Route Covered in
Dashboard /deployment-manager This page
Releases /deployment-manager/releases Releases
Create a release /deployment-manager/releases/create Releases
Release details /deployment-manager/releases/:id Releases
MEP runbook /deployment-manager/mep/:releaseId MEP Runbook
Configuration /deployment-manager/configuration Configuration

Walkthroughs

On a new install, do these in order:

  1. Configuration — environments, sign-off roles, tag patterns and the release-notes template. A release created before these exist inherits nothing sensible.
  2. Releases — create the release.
  3. MEP Runbook — execute it.

Scenario

Your first release on a new install.

  1. Configuration › Environments — declare the environments a release can target, and which clusters are allowed for each.
  2. Configuration › Release Sign-offs — decide who must approve. Doing this before the first release is far easier than retro-fitting approval to a process people already have habits about.
  3. Configuration › Release Notes Template — set the template, so every release describes itself the same way.
  4. Releases — run the creation wizard.
  5. MEP Runbook — execute the release and watch it through.
  6. Production — confirm the environment reflects it.

Skipping step 2 is the common shortcut, and it is the one that turns the release record from an audit trail into a diary.

When it doesn’t work

Symptom Cause How to check Fix
Deployments is not in the submenu Missing deployment-manager.access Access Explorer Ask for a role granting it
Can see releases but not open one access without release.view.details Access Explorer Ask for the details permission
Cannot create a release Missing deployment-manager.release.create Access Explorer Ask for it
A configuration tab is read-only Configuration permissions are per area Access Explorer Ask for the specific config.<area> permission
Production does not match a release Someone acted directly on the environment Production Events tab Reconcile here so the record stays true

Next