How codev ships changes
The delivery model behind every codev screen — packages, artifacts, domains, and the lifecycle a change moves through from merge to release.
Last updated
Was this helpful?
The delivery model behind every codev screen — packages, artifacts, domains, and the lifecycle a change moves through from merge to release.
Everything codev does — builds, validations, release candidates, releases — follows one delivery model. This section explains that 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.
Your project is organised into 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: unlocked and org-dependent unlocked (formal Salesforce packages), source (a deployable collection of metadata), diff (the difference between two states), and data (records managed as files).
Full detail: Package vs artifacts · Supported package types.
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.
A domain groups related packages into an independently releasable unit, defined by a release configuration file in your repository. Builds, release candidates, and releases are organised per domain. See Domains for managing them in codev.

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.
Last updated
Was this helpful?
Was this helpful?