Skip to content

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

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.

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 — 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.

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 for the naming invariant, environment-to-subscription topology, and resource discovery strategy.