Environments
What Is an Environment in ArchRepo?
An Environment is a named deployment environment — Dev, Test, UAT, Staging, Production — that holds the physical technical model of what is deployed there. Each Environment documents the applications, services, APIs, data stores, event streams, and technologies that are running in that environment.
Environments are referenced using the prefix ENV- — ENV-1, ENV-2, and so on.
The Physical Technical Model
An Environment is not just a label — it is the physical model of that environment. Each component is explicitly linked to the environments it is deployed in.
This means:
- An Application may be linked to Dev and Test but not yet to Production — capturing its deployment status accurately.
- A new Data Store introduced mid-project can be linked to the environments where it is live.
- Components can be compared across environments to identify gaps or inconsistencies.
This per-environment model supports completeness checks: “Is every component that should be in Production actually linked to the Production environment?”
Environment Hierarchy
An Environment can contain Infrastructure Environments — the lower-level compute and hosting contexts within it. This supports hierarchical decomposition of complex deployment landscapes:
- A Production environment might contain infrastructure environments for different regions (UK, EU, US).
- A Dev environment might contain a shared cloud infrastructure environment and a local developer environment.
The Contains Infrastructure Environment relationship links a high-level logical environment to its underlying infrastructure environments, enabling the full deployment topology to be documented at the right level of detail.
Concerns: Build, Transition, and Operations
Environments appear across three concerns in ArchRepo:
| Concern | Why Environments appear here |
|---|---|
| Build | Environments are constructed as part of delivery — the Dev and Test environments are built and validated before Production |
| Transition | Environments change during the solution delivery — new environments are stood up, legacy environments are decommissioned, and environment topology evolves |
| Operations | The Production (and other live) environments are the subject of operational governance — monitoring, change management, incident response |
Transition States
Environments support Transition States, which is particularly useful for documenting how the environment landscape changes through the project:
- A new environment being stood up as part of the delivery
- An existing environment being migrated or upgraded
- A legacy environment being decommissioned when the new solution is live
Transition States allow the environment architecture to be documented at each phase of the transition, not just the end state.
Deployability
The Uses Deployability relationship links an Environment to the deployment mechanism that governs it — the CI/CD pipeline, infrastructure-as-code tooling, or release process that is used to deploy into that environment. This makes the deployment architecture explicit and ensures each environment has its deployment approach documented.
Fields Reference
See Environment Fields for a description of each field and guidance on what to record.