Artifact Versioning in CI/CD
From ephemeral build output to attributable release
CI/CD generates artifacts — images, packages, dataset snapshots, model bundles — that only help if they're versioned, immutable and referenced. Versioning in the pipeline is how a build becomes an attributable release.
What you will learn
- Version every pipeline artifact, not just the model
- Make artifacts immutable and referenceable by hash
- Carry versioning through from build to deploy record
What is this?
Artifact versioning in CI/CD assigns each pipeline output — build image, model bundle, dataset snapshot, feature manifest — an immutable version and hash, and threads that identity through to the deployment record. Unversioned artifacts are indistinguishable from each other tomorrow morning.
Why do you need it?
- 'Which build was this really?' is a release-blocking question without versions.
- Immutability means the artifact you validated is the artifact you served.
- Hashes catch silent corruption and prove provenance for audits.
- Rollback and comparison require addressable prior artifacts.
Mental model
Wine bottles with vintage and lot number
Versioned pipeline artifacts
A vintage (version) plus lot number (hash) tells you exactly what's inside, when it was made and where it came from. An unlabeled bottle is fine at the party but useless for a recall.
How it works
- Each build step emits an artifact plus a manifest: version, hash, source SHA, inputs.
- The build tag encodes provenance (sha-<commit>-<run> or semantic version).
- Artifacts are pushed to an immutable store/registry; overwrites are forbidden.
- Deployments reference the artifact's version + hash, not 'latest'.
- The registry records artifact → model → deployment lineage.
Artifact identity from build to deploy.
In production
- A release pipeline tags images with the git SHA and populates an SBOM manifest.
- A model bundle's hash is recorded at registration and asserted at load in prod.
- Rollback resolves 'last known good build' from the deploy registry, not memory.
Best practices
- Version by immutable identity: semantic version + content hash.
- Never tag 'latest' in production references.
- Ship manifests (SBOM, data versions) alongside every build.
- Enforce write-once on the artifact store.
Common mistakes
- Rebuilding the same 'v1' image on each deploy and relying on luck.
- Referencing 'latest' in prod, so two clusters may serve different artifacts.
- Hashing after upload (not before), so corruption is masked.
- Versioning the code but not the dataset or model bundle it consumed.
Debugging tips
- 'Prod and staging behave differently' — diff the artifact hashes, then the input versions.
- 'Can't reproduce the release' — you lost the manifest; make manifests a required artifact.
- Silent corruption in prod — the store allowed overwrite or the hash never covered content.
Interview checkpoint
Quick quiz
What makes an artifact reliably attributable?
An artifact store should allow overwrites to keep things tidy.