From Source to Artifact: The Build & Dependencies

Getting code to users starts with a deceptively important step: turning the source a person wrote into a single, runnable, versioned package — an artifact — with all its dependencies pinned to exact versions. A reliable build of that artifact is the foundation everything downstream depends on.

The big idea is "build once, promote everywhere": you build the artifact a single time, test that exact thing, and then move that same package through to production — never rebuilding along the way, so nothing can change underneath you.

Think of sealing a meal-kit box. Every ingredient is measured and fixed inside, so the dish comes out the same in any kitchen. The artifact is that sealed box — self-contained and identical wherever it's opened.

Source code

→

Build

→

Test

→

Package

→

Artifact

The Build, Recapped

From Chapter 6, the build is the step that turns source into something runnable — compiling it, bundling its pieces, and packaging it up. Here we care about its output: a deployable thing you can put on a server and run. The build is also where many checks run (it can fail if something's wrong), which is why a green build is a precondition for shipping at all.

Pinning Dependencies

Recall that software leans on libraries (Chapter 6). For a trustworthy build, those dependencies are pinned to exact versions — not "the latest", but "this precise version". Pinning means every build pulls in identical code, so the artifact built today is the same as the one built next week. Unpinned, drifting dependencies are a classic source of "it worked yesterday" mysteries.

Artifacts

The artifact is the immutable package the build produces — the exact bytes that get tested and then deployed, unchanged. Because it doesn't change after it's built, you can test it thoroughly once and trust that the very same thing reaches production. Treating the artifact as immutable, and promoting that one package forward, is what makes releases predictable rather than a fresh roll of the dice each time.

Reproducibility

Reproducibility is the goal behind all of this: the same input should always produce the same output, on any machine, at any time. A reproducible build means the artifact doesn't depend on some quirk of one developer's laptop or the day it happened to be built. It's what lets a team say with confidence that what they tested is exactly what users will run — the bedrock of reliable shipping.

Each Cadence build produces a versioned artifact with its dependencies locked to exact versions. The same package the team tested is the one that reaches users — no surprise from a library that quietly updated overnight. When something works in testing, it works in production, because it is, byte for byte, the identical thing. That predictability is what lets the team ship without holding their breath.