Stop 06 · CI/CD PipelinesTopics · 7/10

Artifact Management (Nexus, JFrog)

In short

If staging tested build #41, production should run build #41, not a fresh rebuild that might differ. Artifact repositories store each build once so every environment gets exactly the same thing.

Storing built artifacts (compiled binaries, Docker images, packages) in a dedicated repository so they can be versioned, reused, and deployed reliably rather than rebuilt every time.

The mascot behind a chemist counter checks medicine boxes neatly lined up on labelled shelves.

Think of it like this

Batch numbers on medicine strips

Every medicine strip at the chemist has a batch number and expiry date. If one batch has a problem, the company recalls exactly that batch, not every tablet ever made. Artifact repositories give each build a version and keep it safe, so you always know what you shipped.

Watch it happen

One build, promoted through environments

api:1.4.0

api:1.4.1

api:1.4.2

api:1.5.0

new

1/4CI builds the code once and pushes api:1.5.0 to the repository.

The big ideas

What you need to know

Build once, deploy many

The artifact that passed tests is the one that ships. Rebuilding for prod risks different dependencies sneaking in.

One home for many formats

Nexus and JFrog Artifactory store Docker images, npm, Maven, PyPI and plain files in one place.

Proxy public registries

They can cache npm or Docker Hub, so builds keep working when the internet or the public registry is slow.

Retention rules

Old snapshot builds pile up fast. Set cleanup policies, but keep every release version you might roll back to.

See it in code

Walk through the code

bash

1# Build once, tag with version + commit2VERSION=1.4.23GIT_SHA=$(git rev-parse --short HEAD)4docker build -t registry.example.com/shop/api:$VERSION-$GIT_SHA .5docker push registry.example.com/shop/api:$VERSION-$GIT_SHA6 7# Upload a non-container artifact to a Nexus raw repository8curl -fsS -u "$NEXUS_USER:$NEXUS_PASS" --upload-file dist.tar.gz \9  "https://nexus.example.com/repository/releases/shop/$VERSION/dist.tar.gz"10 11# Promote: staging and prod pull the SAME tag, never rebuild12docker pull registry.example.com/shop/api:$VERSION-$GIT_SHA

1/3Build an image tagged with both the release version and the commit, then push it.

Release repositories are usually set to block overwriting a version, so 1.4.2 can never quietly change after it ships.

Save yourself the pain

Common mistakes

Oops

Deploying the latest tag everywhere, so nobody knows which build is actually running.

Do this instead

Deploy immutable version tags like 1.4.2-a1b2c3d. latest changes under your feet.

Oops

Rebuilding from source separately for staging and production.

Do this instead

Build once, store the artifact, and promote that same artifact from environment to environment.

Your mission

Run a local registry

~25 min

Quick check

Staging tested image api:2.3.0. What should production deploy?

Go deeper

1Learn the basic concept of publishing and pulling an artifact from a repository manager.
2Explore Nexus or JFrog Artifactory's free tier or documentation at a conceptual level.
3Understand why artifact versioning matters for reliable rollbacks.