Environments

An environment in codev is a Salesforce org that codev deploys to and tracks — a sandbox or a production org, registered to your project. The Environments page is where you see them all, grouped by how they are used, with each one's status, the branch it tracks, and what has been deployed to it.

The Environments page — environments grouped by category, each with its status, branch, and recent deploys

Environments and orgs

A Salesforce org is the platform itself — a sandbox, a scratch org, or your production org. codev can connect to many orgs, and you register and manage them under Ops.

An environment is a registered org that you have given a role in your project's delivery. Making an org an environment is what lets codev deploy to it automatically, track which release is on it, gate access to it with a lock, and report its health. An org that is only registered is just somewhere codev can authenticate; an environment is an org codev actively manages as part of your pipeline.

One org backs exactly one environment per project, identified by its username (for example [e-mail]). Orgs handed out from a pool are different again — they are created and destroyed on demand rather than kept as standing environments.

Categories

Environments are grouped into categories that reflect their role in delivery:

• Test — receives builds automatically when code is merged, for early validation. See Builds.
• Snapshot — a known-good copy of a branch, kept current as a source for sandbox pools and for hotfix validation.
• Release — the production-like environments a release is promoted to: staging, UAT, production. Releases reach these through the release flow with an approval gate, not on every merge.

The counters at the top — Environments, Active, Locked — summarise the project, and the Branch filter narrows the list to environments tracking a particular branch.

What each environment tracks

Each environment card shows the branch it is associated with, whether it is Active, whether it is currently In use (locked), the Salesforce org it points at, and its most recent deploys.

The branch association is what decides where a build is deployed: when code is merged, codev deploys the result to the Test and Snapshot environments that track that branch. The branch can be an exact name or a glob pattern such as release/* — see Deploying to environments by branch.

Use Create, or the + on a category, to add an environment; Deactivate takes one out of rotation without deleting it.

The environment detail page

An environment's detail page — current release, tests, artifacts, health, and its access lock

Opening an environment shows the full picture of that org: the current release deployed to it, the latest tests and coverage, the artifacts installed, a health summary, and its locks. The sections down the page cover Access & Locks, Artifacts, Tests, Browser Sessions, and Settings, and Open in Salesforce jumps straight into the org.

Exclusive access and the lock shown here are covered in Access and locks.

Component checksum skip

When codev deploys a changed source or diff package, it deploys only the components whose source changed since the version already on the org, rather than the whole package. This is on by default for every environment.

An environment's Settings carry a Component Checksum Skip switch. Turn it off to force full deploys to that environment — for example, to keep production deploying every component while sandboxes deploy only what changed. The same switch appears when you create an environment.

The Component Checksum Skip switch in an environment's settings. Turning it off forces full deploys to that environment.

A project-wide master switch in project settings turns the optimisation off across every environment and workflow at once — the widest of the controls. Open the project's configuration editor and set Checksum Skip under Configuration.

The Checksum Skip master switch in project settings. Set to false, it turns the optimisation off across every environment and workflow.

For what is skipped, the component types always deployed, and how it falls back, see sfp: Component checksum skip.

Related

The Environments area also links to a few related views:

• Pools — pools of ephemeral sandboxes and scratch orgs. See Pools.
• Deployment Matrix — a grid of which package version is on which environment.
• Org Limits — Salesforce governor and storage usage per org.
• Environment Drift — detect when an org has drifted from what codev believes is deployed.