Artifact
A by-product of the software development process, such as a compiled binary, a library, or a container image.
Detailed Explanation
In CI/CD pipelines, artifacts are the 'output' of the build stage. For example, a frontend build produces a directory of static files; a backend build might produce a JAR file or a Docker image. These artifacts are stored in a registry and are what actually gets deployed to the servers, ensuring that the code tested is the exact code released.
Quick Summary
An artifact is the immutable, deployable output of a build, a tarball, container image, JAR, wheel, or static bundle. Build it once, store it in a registry, and promote that same artifact from staging to production unchanged.
Key Takeaways
- Immutability is the point: once tagged, the artifact cannot be modified, only superseded.
- Tag artifacts with the git SHA (and optionally a semantic version) so you can trace exactly what code is running.
- Promote the same artifact across environments rather than rebuilding per stage, rebuilding reintroduces variability.
- SBOMs and signatures (Sigstore, Cosign) attach provenance metadata so you can prove what's inside.
- Retention policies matter, registries fill up fast; keep recent builds plus tagged releases, prune the rest.
When to use it
- Container images shipped to Kubernetes, ECS, or Cloud Run.
- Frontend bundles uploaded to a CDN with content-hashed filenames.
- Backend JARs/WARs deployed to JVM app servers.
- Language packages (npm tarballs, PyPI wheels) published for downstream consumers.
Common Mistakes
- Rebuilding the same code separately for staging and production, then debugging why they behave differently.
- Using mutable tags like `latest` in production, so rollback to "the previous artifact" becomes ambiguous.
- Storing build outputs only on the CI runner, where they disappear when the runner is recycled.
- Ignoring signing and provenance, leaving the supply chain unverifiable.
Artifact, Frequently Asked
What's the difference between an artifact and a release?
An artifact is the binary or bundle a build produces. A release is the decision to promote a specific artifact to a specific environment. One artifact can be released many times to different stages.
Should I version artifacts with semver or git SHA?
Both, ideally. Git SHA gives exact traceability per build; semver gives consumers a stable contract for breaking vs. compatible changes. CI typically tags every build with a SHA and additionally publishes semver tags on release.
Where do I store artifacts?
Container images go in a registry (ECR, GHCR, Docker Hub). Language packages go to their ecosystem registries (npm, PyPI, Maven). Raw build outputs go in object storage (S3, GCS) or generic artifact stores like Artifactory or GitHub Artifacts.