Zerethon IDE
Sign in

Build artifacts and versioning

Intermediate 10 min read

Build once, give the result a version, and deploy that same artifact to every environment.

Why it matters

If staging and production each build from source, they can end up running different code. Building one versioned artifact and promoting it through environments means what you tested is exactly what users get — and rolling back means redeploying the previous version.

Where it fits

  1. Plan & Design
  2. Develop
  3. Version control
  4. Verify
  5. ● Build & Package
  6. CI/CD
  7. Deploy
  8. Operate

What you will learn

  • Explain what a build artifact is for your stack.
  • Version releases with semantic versioning.
  • Trace a running deployment back to its commit.

Before you start

What an artifact is

The output of the build: a frontend bundle, a .jar, a compiled binary, a Python wheel or a container image. It contains everything needed to run except configuration and secrets.

  1. Commit
  2. Build + test once
  3. Artifact v1.4.2
  4. Staging
  5. Production

Semantic versioning

  • MAJOR (2.0.0) — an incompatible change.
  • MINOR (1.5.0) — a new feature that stays compatible.
  • PATCH (1.4.3) — a compatible bug fix.
Example 
git tag v1.4.2
git push origin v1.4.2
docker build -t registry.example.com/app:1.4.2 .
docker push registry.example.com/app:1.4.2

Tip: Never overwrite a published version. If 1.4.2 is wrong, release 1.4.3 — otherwise nobody can tell which "1.4.2" a server runs.

Official documentation and references

Specifications

Learn next

Related topics

Done with this topic?

Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.