DEVOPS / A CONCEPT NOTE
Artifact Management
storing, versioning, and distributing build outputs
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
After CI builds your code, the output — a Docker image, JAR, npm package, or binary — is pushed to an artifact registry (Docker Hub, ECR, Artifactory, GHCR). Each artifact is immutable and tagged with a version or commit SHA. Deployments pull the exact same artifact that passed testing, eliminating 'works on my machine'.
02 / FOLLOW THE MECHANISM
How an artifact moves from build to deploy
CI pipeline
builds the artifact and tags it with the Git commit SHA (e.g.,
myapp:abc1234).CI pipeline
authenticates to the artifact registry and pushes the artifact with its tag.
Registry
stores the artifact, scans it for vulnerabilities, and makes it available via pull API.
CD pipeline
pulls the exact artifact by its SHA tag into the target environment, guaranteeing the same bits that passed tests.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
pull an exact artifact by SHA
docker pull ghcr.io/myorg/myapp:abc1234tag an image with a semantic version
docker tag myapp:latest myapp:v1.2.305 / CHECK YOURSELF
Could you explain Artifact Management to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Delivery & operationsCanary Deploymentsrolling out changes to a small subset before full release