Build artifact
What it is
A build artifact is a named set of files a pipeline publishes for later use. It can contain a compiled application, a zipped web site, deployment manifests, test evidence, or another output needed by a later job or deployment stage.
Why it exists
Different jobs and stages can run on different agents with clean workspaces. Publishing an artifact gives the next stage an explicit, reproducible input instead of assuming the build files are still on the same machine.
Key ideas
- Publish then download. Azure Pipelines can publish a Pipeline Artifact with
publishorPublishPipelineArtifact, then download it in a later stage or another pipeline. Name the artifact for what it contains. - Artifacts make promotion reliable. The production stage should download the binary or package that passed earlier validation, not rebuild it from a moving branch.
- Retention is part of the design. Deleting an Azure Pipelines run deletes its associated artifacts. Retain the evidence and deployable output for as long as your recovery, audit, and release process needs.
- Artifact is not the same as a package. A pipeline artifact is build output associated with pipeline use. A package in a package feed, such as NuGet or npm, has a versioned distribution lifecycle and its own immutability rules.
Northwind example
Northwind’s CI job compiles the order API, creates order-api.zip, and publishes it as the order-api artifact. The staging and production jobs each download that named artifact. If production needs a rollback, the team can choose a previously retained, known-good artifact rather than asking the build server to recreate old code from memory.
Exam notes
- Publish artifacts when a later job, stage, or pipeline must consume build output.
- “Build once, promote the same artifact” reduces accidental differences between test and production.
- Plan retention: deleting a pipeline run can remove its associated artifacts.
Related
azure-pipelines · github-actions · jobs-steps
📘 Source: Microsoft Learn — Build Artifact