How codev ships changes
The delivery model behind every codev screen — domains, packages, artifacts, and the lifecycle a change moves through from merge to release.
codev is repository-first: a project in codev maps to a repository, and what codev manages is what that repository declares — the packages its project configuration lists, grouped into domains by its release configurations. codev builds those packages from the repository's branches and moves them into the project's environments: Salesforce orgs bound to the project, each with a role.
Everything codev does — builds, validations, release candidates, releases — follows one delivery model over that repository. This section explains the model, so the statuses and behaviours you see on screen are predictable. Each concept links to a reference page with the full mechanics for when you need more depth.
The repository and the org
Two models are common for managing a Salesforce org. In an org-centric model, one org is compared with another, components are selected from the difference and deployed, and an environment's history is the list of deployments it received; the whole org is the surface being compared. In a repository-first model, a repository declares packages, each package is built into a versioned artifact, an environment's state is the record of artifact versions installed into it, and only what the repository declares is in scope. codev follows the second model.
The repository is not necessarily the whole org. An org can hold metadata the repository does not declare: managed packages, configuration made directly in the org, metadata that has never been brought under source control. That part of the org is outside codev's model. A release installs the repository's packages and does not touch metadata outside them, and a drift check compares the org against the packages the repository declares, component by component, and nothing else. How much of the org the repository covers — one domain, a few packages, or all of it — is decided by the project, not by codev; the model is the same either way.
Within what the repository declares, the org is not the source of truth. What an environment should contain is answered by the branch it tracks and the releases that reached it, not by what is currently in the org. When the org differs from that, the difference is drift. Sync deploys a pull request's state to an environment on demand, and a changeset captures a change made in an org and raises it as a pull request, so the change enters the repository instead of standing as drift. Org Explorer is where codev shows an org beyond the repository's scope: it browses everything in the org, not only what the project declares.
Day-to-day administration of the orgs themselves — creating and refreshing sandboxes, access grants, user freezes — lives in Operations, which is instance-wide and acts on orgs directly.
Projects
Your work happens inside a project — codev's mapping of a repository. Everything on screen is scoped to the selected project: its branches, domains, builds, release candidates, releases, and environments. Orgs, teams, and Operations sit at the instance level, shared across projects. Full detail: Projects.
Domains
A project is organised into domains — independently releasable units that typically mirror business capabilities: sales, service, platform. A domain is defined by a release configuration file in your repository and groups the packages that ship together. Everything codev shows is organised per domain: a merge builds the affected domains, release candidates collect per domain, and a release ships one domain. Full detail: Domains.
Packages
Each domain is made of packages — directories of metadata and code declared in the project configuration. A package is the unit codev builds, versions, validates, and installs. Packages come in types with different behaviours: source (the default — a deployable collection of metadata), unlocked and org-dependent unlocked (formal Salesforce packages), diff (the difference against a baseline), and data (records managed as files).
Full detail: Package types · Package vs artifacts.
Artifacts
When codev builds a package, the result is an artifact: the package's contents at a specific version, together with its dependencies and its installation behaviour. Artifacts are immutable — how a package installs (which components can be skipped, which orgs it skips, its deployment scripts) is baked in at build time. Changing an installation behaviour means building a new version.
Built artifacts are published to your package registry, and everything downstream — validation, release candidates, releases — works with those published versions. The Packages page lists every built version.
The lifecycle
- A pull request validates. The changed packages are deployed to a review environment and tested — see Validation.
- A merge builds. codev builds new versions of the changed packages and publishes the artifacts — see Builds.
- A release candidate collects. New versions accumulate on a release candidate per domain — see Release candidates and releases.
- A release installs. The candidate's artifacts install into an environment, in dependency order, each following its installation behaviour — see Package installation and Releases.