How codev ships changes

codev is repository-first: a project in codev maps to a repository, and codev tracks that repository's state — the domains and packages its branches define — and moves it into the project's environments: Salesforce orgs bound to the project, each with a role. The org is never the source of truth — what an environment should contain is answered by the branch and the releases that reached it, differences surface as drift, and Sync reconciles them. Day-to-day administration of the orgs themselves lives in Operations.

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.

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

1. A pull request validates. The changed packages are deployed to a review environment and tested — see Validation.
2. A merge builds. codev builds new versions of the changed packages and publishes the artifacts — see Builds.
3. A release candidate collects. New versions accumulate on a release candidate per domain — see Release candidates and releases.
4. A release installs. The candidate's artifacts install into an environment, in dependency order, each following its installation behaviour — see Package installation and Releases.