For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

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.

Packages

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.

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.

Domains

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.

The lifecycle

The codev lifecycle — a pull request is validated on a review environment, the merge builds versioned artifacts, versions collect on a release candidate per domain, and a release installs them into an environment
From pull request to released artifact — the lifecycle every change moves through.
  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.

Last updated

Was this helpful?