Artifact Repository: Your CI/CD's Private Library

WHY IT EXISTS: Building from source code every single time is slow, inconsistent, and doesn't scale. You need a reliable, central place to store the results of a build—the artifacts—so they can be shared, tested, and deployed predictably without being rebuilt.

THE MENTAL MODEL: Think of an artifact repository as a private, version-controlled library for your compiled code. Instead of checking out books (source code) from a public library (GitHub), you're publishing your own finished books (artifacts) to a private shelf (the repository) where others in your organization can reliably find and use them. It stores the "what" (the binary) and the "how" (metadata like version, build number, and dependencies).

HOW IT WORKS: A CI server, like Jenkins or GitHub Actions, runs a build. On success, it packages the output, such as a .jar file or a Docker image. It then uses a client tool like Maven, npm, or the Docker CLI to "push" this package, along with metadata like its version, to the artifact repository (e.g., Nexus, Artifactory). Other projects or deployment scripts then configure their package managers to pull from this repository, treating it as a trusted source for dependencies.

WHEN TO USE IT: Use an artifact repository to store and share any binary output from a build process that needs to be consumed by other teams, systems, or environments. This is essential for managing dependencies between microservices, sharing internal libraries, and ensuring deployments use a consistent, tested version of the software. It also acts as a cache for public dependencies, improving build speed and reliability.

WHEN NOT TO USE IT: Do not use it for source code; that's what version control systems like Git are for. It is also not a general-purpose file storage system like Amazon S3. Its power comes from understanding package formats and managing versions and metadata, so using it for random, unstructured files is overkill and misses the point.

ONE CANONICAL EXAMPLE: A Java project's CI pipeline successfully builds and tests a new version of a shared library, common-utils-1.2.3.jar. The pipeline then uses Maven to deploy this JAR file to an Artifactory instance. Another team's project, which depends on common-utils, can now update its configuration to use version 1.2.3, and their next build will automatically download the new JAR from Artifactory.