Before this:What is deployment?
Build artifacts & versioning
Key takeaways A build artifact is the concrete thing you deploy — a binary, a container image, a tarball. Build it once and ship that same immutable artifact everywhere, rather than rebuilding per machine. Label each with a version (often SemVer: MAJOR.MINOR.PATCH) so you know exactly what’s running and can roll back to a known- good one instantly.
Before you can deploy something, you have to know precisely what that something is. This lesson is about the artifact you ship and how versioning keeps releases sane.
What a build produces
Compiling or packaging your software yields an artifact — the deployable output. What it looks like depends on the stack:
| Stack | Typical artifact |
|---|---|
| Go (like GopherTrunk) | a single static binary |
| Any language, containerized | a container image |
| Python / Node | a package or a zip of files |
Because Go compiles to one self-contained binary,
GopherTrunk’s artifacts are simple: a gophertrunk executable per platform. Its
release process builds Linux, macOS, and Windows artifacts and publishes them with
checksums.
Build once, deploy that exact thing
The key discipline: an artifact is immutable, and you deploy the same one everywhere. Rebuilding on each server invites the “works on my machine” gremlins from lesson 1 — a slightly different compiler, library, or timestamp. Build the artifact a single time, test that artifact, and promote the very same bytes from staging to production. What you tested is exactly what you ship.
Versioning: naming what you ship
Every artifact needs a version so you can talk about it precisely. The common scheme is semantic versioning:
1 . 4 . 2
MAJOR MINOR PATCH
| | |
| | +-- backward-compatible bug fixes
| +---------- backward-compatible new features
+------------------ breaking changes
GopherTrunk stamps the version into the binary at build time — its build injects the
tag via Go’s linker (-ldflags "-X …version.Version=<tag>"), so a running instance can
report exactly which release it is. Versions usually come from
Git tags: tag v1.4.2, and the release build produces
the 1.4.2 artifacts.
Why versioning enables rollback
Immutable, versioned artifacts give you a safety net. If v1.4.2 misbehaves in
production, you don’t debug live — you roll back by redeploying the previous
known-good v1.4.1 artifact, which still exists untouched. That ability to instantly
return to a working version is one of the biggest reasons to build discrete, versioned
artifacts, and it underpins the safe-update practices in
monitoring & updates.
Quick check: why build an artifact once and deploy that same artifact everywhere?
Recap
- A build artifact is the deployable output — a binary, image, or package.
- Build it once and deploy the same immutable artifact everywhere.
- Version each artifact (often SemVer MAJOR.MINOR.PATCH); GopherTrunk stamps the version into the binary.
- Versioned artifacts make instant rollback to a known-good release possible.
Next up: Unit 2 — the technology that bundles an artifact with everything it needs: containers.
Frequently asked questions
What is a build artifact?
A build artifact is the concrete output of compiling or packaging your software — a binary, a container image, a zip file — ready to run or deploy. The idea is to build it once and deploy that exact same artifact everywhere, rather than rebuilding on each machine and risking subtle differences.
What is semantic versioning?
Semantic versioning (SemVer) labels releases as MAJOR.MINOR.PATCH — for example 1.4.2. You bump PATCH for backward-compatible fixes, MINOR for backward-compatible new features, and MAJOR for breaking changes. The scheme lets anyone tell at a glance how risky an upgrade is.