Deployment Configuration
What this screen is for
Configuration sets the rules every release follows: which environments a release can target, who must sign it off, how notifications are sent, and what release notes look like.
Set this up before your first release. These settings shape releases created afterwards, and retro-fitting approval rules to a process people already have habits about is much harder than starting with them.
Before you start
Each tab has its own permission, so responsibilities can be split:
| Tab | Permission |
|---|---|
| General Settings | deployment-manager.config.general |
| Environments | deployment-manager.config.environments |
| Release Sign-offs | deployment-manager.config.signoff-roles |
| Notifications | deployment-manager.config.notifications |
| Release Notes Template | deployment-manager.config.release-notes-template |
Two further permissions cover areas configured alongside these:
deployment-manager.config.jira and deployment-manager.config.tag-patterns.
A tab you lack the permission for is read-only or absent. That is the design — someone can own notifications without being able to weaken sign-off rules.
Opening it
- Deploy › Deployments, then Configuration.
Direct URL: /deployment-manager/configuration
The interface
📸 Screenshot Placeholder: The Configuration page on the Environments tab. Mark: (1) the five tabs, (2) the Allowed Clusters field, (3) save.
| Tab | What it configures |
|---|---|
| General Settings | Overall behaviour of the Release Manager |
| Environments | The environments a release can target, and the Allowed Clusters for each |
| Release Sign-offs | Which roles must approve before a release proceeds |
| Notifications | Email recipients — who is told, and when |
| Release Notes Template | The shape every release’s notes take |
Walkthroughs
Declare the environments releases can target
Requires deployment-manager.config.environments.
- Configuration › Environments.
- Add the environment and set its Allowed Clusters.
- Save.
Allowed Clusters is the guard rail: it stops a release aimed at one environment from landing on a cluster that was never meant to receive it.
Set sign-off roles
Requires deployment-manager.config.signoff-roles.
- Configuration › Release Sign-offs.
- Choose the roles that must approve.
- Save.
Roles come from People & Access › Roles. Name a role, never a person — people change teams and the rule should not follow them.
Set the release-notes template
Requires deployment-manager.config.release-notes-template.
Set it once and every release describes itself the same way. The value is in the consistency, not the wording.
Scenario
A release reached the wrong cluster.
Nobody did anything obviously wrong, which points at the configuration rather than the operator.
- Configuration › Environments — find the environment the release targeted.
- Read its Allowed Clusters. If the cluster that received the release is listed, the release did exactly what it was configured to do, and the configuration is what needs correcting.
- Narrow Allowed Clusters to only the clusters that environment should ever reach. Save.
- Configuration › Release Sign-offs — if this could have been caught by a human, add the role that should have seen it.
- Re-check Settings › Infrastructure › Environments. Two environments of the same type on different clusters is the usual way this happens, and the fix may belong there rather than here.
The point of step 2: a release landing somewhere unexpected is nearly always a permitted target nobody intended, not a bug.
When it doesn’t work
| Symptom | Cause | How to check | Fix |
|---|---|---|---|
| A tab is read-only | Configuration permissions are per tab | Access Explorer | Ask for that tab’s config.<area> permission |
| A release can target an unexpected cluster | Allowed Clusters is too broad | Configuration › Environments | Narrow it |
| Sign-offs are not requested | No sign-off roles configured | Configuration › Release Sign-offs | Add the roles |
| A role is missing from the sign-off picker | It does not exist | Roles | Create it, then return here |
| Release notes are inconsistent | No template set | Configuration › Release Notes Template | Set one |
| No environments to choose when creating a release | None declared here | Configuration › Environments | Declare them |
Next
- Releases — create one under these rules
- Settings › Infrastructure › Environments — where environments come from
Slack is configured elsewhere
This tab covers email only. Slack notifications are configured platform-wide under Settings › Development › Integrations, because one Slack workspace is shared by every plugin rather than owned by the Release Manager.