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.
Already installed versions are skipped
The environment 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.
For a source or diff package, the component checksum skip narrows the tests the same way it narrows the deploy: when only the changed components install, the tests relevant to those components run instead of the package's full suite. How installation behaviour weighs into the choice between types: Choosing a package type.
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: Package dependencies.
Validation
What happens when codev validates a change — real deployments to a review environment, Apex tests and coverage, and why the result predicts the release.
Destructive changes
How metadata is deleted from orgs — destructive changes per package type, how they move through validation and releases, and how left-behind components are tracked.