Path · CloudOps and environment owners
Run environments
One folder per environment in cloud-config says what should run there. A commit to it is the only way an environment changes; the environment pipeline and Flux make the cluster match.
The environment pipeline is failing broken
Since 26 October 2026 no environment apply completes, so no promotion can complete either. Fixing it takes two steps: move cloud-config to the current shared workflow (done on 26 October), and publish environment chart 0.5.0, which the current workflow needs (pending). Test environments still receive new candidates through Flux.
No qa or prod environments yet planned
Only dev/app01 exists today. Promotion to qa and prod is not possible until greenfield IaC creates those environments: CD · Promote and CD · Release stop at their first step. On 28 October the other environment folders were removed from cloud-config. They come back when greenfield IaC creates the environments.
What you own
landscapes/
└── <landscape>/ dev, qa, prod, nonprod, preview
├── clusters.yaml subscription, stacks and their clusters
├── environments.yaml landscape defaults
└── <environment>/ app01, app02, …
├── environment.yaml the environment: stack, delivery, identity, product versions, Key Vault
└── <product>/ this environment's settings per component
├── helm.yaml (optional)
├── adf.yaml
└── databricks.yaml
And in Azure, per environment: its managed identity, a federated credential per product namespace and cluster, and the secret values in its Key Vault. Each file explained: Reference: cloud-config.
| Landscape | Environments today | Status |
|---|---|---|
| dev | app01: follows every candidate | built |
| qa, prod | none yet: only the landscape files; greenfield IaC will create the environments | planned |
| nonprod, preview | none yet: only the landscape files | planned |
Steps: add an environment
- Create the environment's managed identity
id-<environment>-<landscape>, one for all its products. - Add a federated credential for
system:serviceaccount:<namespace>:shared-pp-workloadper product namespace and cluster, each with its own name (at most 20 per identity). - Grant it Key Vault Secrets User on the environment's vault, and load the product's secrets into the vault under their pool names.
- Copy an environment folder; change environment, landscape, stack and the identity's client ID at the top of
environment.yaml. - Open a pull request (it renders and checks only). Merging it applies the environment.
Change one setting in one place: edit <environment>/<product>/helm.yaml. Environments may set only an agreed list (settings, size, replicas, autoscaling, on/off and a set of global keys). No new build is needed.
See an environment deploy
What can stop you
| You see | It means | Fix |
|---|---|---|
| Render fails before any cluster call | A stale version pin, a leftover <fill>, a credential-shaped value, a key outside the allowed list, an unknown stack, or names that do not match the folders | Fix the file the message names |
| Environment chart install fails patching namespaces | The deploy principal has namespace-scoped rights only | It needs cluster-scope namespace write |
Pods in CreateContainerConfigError for minutes | A secret is missing from the vault, the identity lacks vault access, or its federated credential does not match | Load the secret under its pool name; check the SecretStore is Ready and the credential subject |
| One environment silently loses Key Vault access | A federated credential was created with an existing name and overwrote it | Give every credential a unique name |
| An override does nothing | It uses a repository name instead of the service name | Use the service name from the service's service-chart.yaml |
| Files with odd diffs or parse errors | Windows line endings (CRLF) | Save with LF endings |
Symptoms, where to look and read-only commands: Deep dive: runbook.