Environments

An environment binds a registered org to a project, giving the org a role in that project's delivery. One org can back environments in several projects; within a project, one org backs exactly one environment. It is the environment — not the bare org — that codev deploys to, tracks, locks, and monitors.

What an environment carries

• A role. Test environments receive builds on merge, for early validation. Snapshot environments hold a known-good copy of a branch, kept current as a source for pools and hotfix validation. Release environments — staging, UAT, production — are reached only through releases, behind approval gates. The environment categories and the principles behind them come from the flxbl framework: Environment management.
• A branch association — for Test and Snapshot environments. They track a branch — an exact name or a glob such as release/* — and a merge's build deploys to the Test and Snapshot environments tracking its branch. Release environments carry no branch association: nothing deploys to them on merge, only a release.
• A deployment record. codev records which artifact versions are installed, which is what lets installation skip versions already present and the Deployment Matrix show every package version across every environment.
• A lock. An environment is used by one thing at a time — flows lock it while they deploy, people request exclusive access, and everyone else queues. See Access and locks.
• Health. Drift detection reports when the org diverges from what the repository shipped, and Org Limits tracks its platform usage.

Managing environments — creating them, categories, the per-environment settings: Environments.

Ephemeral environments

Not every environment stands. Alongside the standing environments above, codev provisions ephemeral environments from pools — pre-built sandboxes and scratch orgs handed out on demand, each assigned for a purpose and a duration, then expired and replaced by its pool. They come in two kinds:

• Review environments carry pull request validation. Assignment rules match each pull request to an environment — a dedicated org shared across PRs, or an isolated sandbox or scratch org fetched from a pool — the changed packages deploy there, and a pooled environment returns when validation is done. See Review environments.
• Dev environments are ready-made orgs a developer fetches from a pool to work in — assigned to the person for a chosen duration, listed under Dev > My Orgs > Assigned to Me, and expired back to the pool when the time is up. See Fetching and using environments.

An ephemeral environment is created, replenished, and cleaned up by its pool; it never appears among the project's standing environments.