# Environments

## 📋 Environment Descriptions

| Environment | Description                                                       | Approver              | Deployment                 |
| ----------- | ----------------------------------------------------------------- | --------------------- | -------------------------- |
| Local       | Active Development on feature                                     | N/A                   | N/A                        |
| Test        | Feature is finished and deploy to full env                        | N/A                   | Continuous Deployment (CD) |
| QA          | Feature is ready for Testers(DEV/QA)                              | Peer/QA               | Continuous with Approval   |
| UAT         | Business and Business Analyst Validate feature meets requirements | Product Owner/Manager | Continuous with Approval   |
| Staging     | Pre Production ready for prod                                     | Peer                  | Continuous with Approval   |
| Production  | Swapped From Staging                                              | Senior Peer/Manager   | Swap with Approval         |

## 🔄 Deployment Flow Diagram

```mermaid
sequenceDiagram
    Local ->> Test: Feature is Complete and ready for integration in Full Environment
    Test ->> Local: Bug was found in feature in full environment
    Test ->> QA: Feature passed integration test is ready for QA Testing
    QA ->> Local: Bug was found in QA Testing
    QA ->> UAT: QA Testing passed ready for Business Users and BA's to Test
    UAT ->> Local: Bug was found by Business Users
    UAT ->> Staging: Application passed on UAT tests and is ready to smoke tested in production like env
    Staging ->> Local: Issue found in Production Tests
    Staging ->> Production: Swap and Ready for Production
    Production ->> Staging: Issues Discovered ready for rollback
```

## 🌳 Branch Strategy

Every deploy pipeline template triggers CI on `main` — Forge's environment flow is trunk-based by
default. This section covers when to rely on that default versus cutting a release branch, and
what the platform team recommends for either path.

!!! note "This is a recommendation, not a mandate"
    The guidance below reflects how the platform team operates Forge's own releases and backports.
    Teams can adapt it to their own branching needs, but trunk-based deployment and treating
    `releases/*` as snapshots are what the platform team recommends as a starting point.

### Trunk-based deployment (preferred)

- Merge to `main` only after a change has been fully tested; `main` is the single source that
  promotes through Test → QA → UAT → Staging → Production in order.
- Test a feature branch in an isolated Azure slot before merging — see
  [PR Slot Deployments](../build/deploy/pr-slot-deployments.md) — instead of merging early just to
  get a build into a shared environment like QA for validation.
- This keeps every environment fed from the same tested, reviewed history and avoids maintaining
  parallel long-lived branches.

### Release branches (`releases/{major}.{minor}`)

- Cut a release branch as a **point-in-time snapshot from `main`**, never as its own line of
  ongoing feature development. `main` stays the trunk; a release branch exists to stabilize or
  patch a version that has already moved past it.
- Never commit directly to a release branch. Land the change on `main` first, then bring it onto
  the release branch by cherry-pick/backport, so the branch never diverges from `main`'s history.
  This is the same model the platform team uses for Forge's own releases and patches.
- Protect `releases/*` with a branch-name-pattern policy (not a per-branch one), so every new
  release branch inherits it automatically:
    - Restrict merge types to **rebase and fast-forward only**, so commits backported from `main`
      resolve cleanly on top instead of producing merge commits that fight later backports.
    - Require the same reviewer approvals as `main`.

## 🔗 Related

Each environment of a service runs in its own Azure subscription, and an environment maps to a
specific Entra application registration and App Service. See
[Service ↔ Azure Resource Model](./service-azure-resource-model.md) for the naming invariant,
environment-to-subscription topology, and resource discovery strategy.