Package installation

How artifacts install into an org — version skipping, component checksum skip, test execution per package type, and the behaviours baked in at build.

When a release runs — or you deploy from your workspace — each artifact installs into the target org following rules that decide what is skipped, what is deployed, and which tests run. Knowing these rules explains the statuses a release shows: why a package reads Skipped, why an install deployed three components instead of three hundred, and why some packages run tests during installation while others do not.

A release installs its artifacts in dependency order — each artifact deciding what it deploys.

Already installed versions are skipped

The org records which artifact versions are installed. If the version to install matches what the org already has, the package is skipped — installing the same release twice does nothing the second time. A package can opt out with the alwaysDeploy behaviour, and skipIfAlreadyInstalled is the release-level control.

Only changed components deploy

When a source or diff package installs a new version over an older one, codev compares the two artifacts file by file and deploys only the components whose contents changed — the unchanged majority of a large package never enters the deployment. This is the component checksum skip: on by default, and strictly additive — whenever the previous artifact cannot be fetched or carries no checksums, the package falls back to a full deploy.

It can be turned off per run, per package (the disableChecksumSkip behaviour), or per project, environment, or target branch from codev's settings. The full mechanism, including its fallbacks: Component checksum skip.

Tests during installation depend on the package type

Package type	Apex tests during install	Coverage requirement
Unlocked	No — validated when the version was built	75% at build
Org-dependent unlocked	No	None
Source	Yes — the package's own test classes run	75% per class, or org-wide coverage
Diff	Yes	75% per class, or org-wide coverage
Data	No — records load via the data engine	None

This is why unlocked packages install faster than source packages carrying many tests: their validation happened once at build time. See Optimized installation.

Behaviours are baked in at build

An artifact is immutable: its installation behaviours are recorded when the version is built, and changing one requires building a new version. The behaviours a package can declare include:

• skipDeployOnOrgs — skip this package on named orgs.
• alwaysDeploy — install even when the same version is already present.
• Aliasfy — deploy an environment-specific variant of the package's metadata per target org.
• String replacements — substitute values in the source per environment at install.
• Pre/post deployment scripts — run scripts around the install.
• Reconciling profiles, picklist updates, field history tracking — type-specific install helpers.

Each is a one-line property on the package; the full catalogue with examples: Configuring installation behaviour of a package.

Order

Artifacts install in dependency order — the order of packages in the project configuration, refined by each package's declared dependencies and the domain's release configuration. Full detail: Dependency management.