Command Palette

Search for a command to run...

Hectal
Phase 5Intermediate6 of 9 in CI/CD

Artifact Management

The build produces something real — a JAR, a container image — and an artifact repository is where it lives, gets versioned, and moves toward production deliberately.

Every pipeline in this course so far has ended with 'and then it's built.' This phase covers what actually happens to that built thing: where it's stored so it can be reliably retrieved later, how container images specifically get pushed and pulled, and the deliberate process of promoting one specific, already-tested artifact through environments rather than rebuilding it at each stage.

0/4 · 0%
4 topics ~55 min 8 code blocks & diagrams
Start with the first topic
1
5.1

Why Artifact Repositories Exist

Rebuilding an application fresh at every stage of a pipeline risks the new build being subtly different from the one that was actually tested — an artifact repository stores the exact, tested binary once, so every later stage uses that exact same thing.

14 min 1 diagram 1 code practice

2
5.2

Nexus & JFrog Artifactory

Nexus and JFrog Artifactory are the two most widely used self-hostable artifact repositories — both act as a proxy and permanent store for exactly the kind of binary dependencies Phase 0.3's build tools already know how to fetch.

13 min 1 diagram 1 code practice

3
5.3

Container Registries: ECR, GHCR, and Docker Hub

A container registry is an artifact repository specifically for Docker images — the exact same build-once-store-retrieve principle from Topic 5.1, applied to the images Docker's own course taught you to build.

14 min 2 code practice

4
5.4

Versioning & Promotion Strategies

Promotion is moving one specific, already-built, already-tested artifact forward through environments deliberately — the deployment-pipeline expression of Topic 5.1's build-once principle, tied together with real version numbers.

14 min 1 diagram 1 code practice