The Hook (The "Byte-Sized" Intro)
You don't ship your Git commits to users. You ship the thing those commits build — a binary, a Docker image, a compiled bundle. Those are build artifacts: the finished products that CI creates from a specific commit or tag. If your artifacts aren't reproducible (same commit → same artifact every time), you can't trust what's running in production.
📖 What are Artifacts and Builds?
Build artifacts are the output files produced by a CI/CD pipeline from a specific commit. They include compiled binaries, packages, container images, and static bundles.
Conceptual Clarity
Common artifact types:
| Artifact | Example | Ecosystem |
|---|---|---|
| Binary executable | myapp.exe, myapp | Go, Rust, C++ |
| Package | mylib-1.2.0.tar.gz | npm, PyPI, Maven |
| Container image | myapp:v1.2.0 | Docker |
| Static bundle | dist/, build/ | React, Vue, Next.js |
| Mobile build | app.apk, app.ipa | Android, iOS |
Key principles:
| Principle | Why It Matters |
|---|---|
| Reproducible | Same commit should always produce the same artifact |
| Immutable | Once published, never modified |
| Traceable | Artifact links back to the exact commit/tag |
| Versioned | Artifact version matches the Git tag |
Real-Life Analogy
Commits are ingredients. The CI pipeline is the kitchen. Artifacts are the finished dishes. You send the dishes to customers — not a list of ingredients. And a good kitchen produces the same dish from the same recipe every time.
Visual Architecture
Why It Matters
- Reproducibility: "Works on my machine" is eliminated — CI builds are the source of truth.
- Traceability: Every artifact links back to a specific commit, enabling debugging.
- Rollback: Deploy a previous artifact instantly instead of rebuilding from source.
- Security: Artifacts can be signed and verified for authenticity.
Code
# ─── GitHub Actions: Build and upload artifact ───
name: Build Release
on:
push:
tags: ['v*']
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build
- uses: actions/upload-artifact@v4
with:
name: dist
path: dist/
- uses: softprops/action-gh-release@v2
with:
files: dist/**# ─── Docker: build and tag from Git tag ───
docker build -t myapp:v1.2.0 .
docker push registry.example.com/myapp:v1.2.0
# ─── Verify artifact traceability ───
git log v1.2.0 -1 # What commit built this artifact?Key Takeaways
- Artifacts are the build outputs that CI produces from a commit or tag.
- Artifacts must be reproducible, immutable, traceable, and versioned.
- Deploy artifacts — never build directly on production servers.
- Tag-triggered builds ensure the artifact matches the release version exactly.
Interview Prep
-
Q: Why should build artifacts be reproducible? A: Reproducibility ensures the same commit always produces the same artifact. Without it, you can't trust that what's in production matches what was tested. Non-reproducible builds make debugging deployment issues nearly impossible.
-
Q: Why should you deploy pre-built artifacts instead of building on the deploy server? A: Pre-built artifacts are tested and verified by CI. Building on the deploy server introduces variables (different OS, different dependencies) that can produce a different result. Deploy the exact same artifact that passed all tests.
-
Q: How do you trace a running artifact back to its source code? A: The artifact version should match a Git tag.
git show <tag>reveals the exact commit. Many teams also embed the commit SHA or build number directly into the artifact as metadata.