The Problem of Inter-Stage Data
Consider what happens when your Build stage compiles source code into a binary — say, app-v1.jar. The Test stage needs that exact binary to run integration tests against. The Deploy stage needs that same binary to ship to a server. But each stage (and often each job) runs in a fresh, isolated environment. Files created in one job do not automatically appear in another.
Artifacts solve this. An artifact is any file or directory produced by a job that the CI/CD system saves and makes available to subsequent stages. The Build job "uploads" the artifact to the pipeline's storage layer. The Test job "downloads" it before running.
Artifact Promotion: Build Once, Deploy Many
A foundational principle of release engineering is build once, promote many times. You build an artifact exactly once. You then promote that same, immutable artifact through a series of environments — Dev → Staging → Production — after it passes the gate tests in each environment.
The alternative — rebuilding the artifact for each environment — is dangerous. Even with identical source code, two builds can produce subtly different outputs due to differences in dependency versions, build tool behavior, or environment variables. If you test one binary and deploy a different one, your test results are meaningless.
Retention Policies
Artifacts consume storage. A busy team might run hundreds of pipelines per day, each producing multiple artifacts. Without cleanup, storage costs balloon. Retention policies define how long artifacts are kept:
- Test reports and logs: typically 7–30 days
- Release binaries for production deployments: often kept indefinitely or until the next major version
- Intermediate build artifacts: often expired after 1–3 days
Most CI/CD platforms let you configure retention at the job level. Setting sensible defaults early prevents a storage crisis later.