Design a versioning strategy for pipeline artifacts

An artifact version and its retained pipeline metadata should let you answer, months later: which run produced this artifact, and which source version did that run build?

Run numbers

yaml

name: $(Date:yyyyMMdd)$(Rev:.r)

name sets the run number (Build.BuildNumber). $(Rev:.r) is the auto-incrementing counter that resets when the rest of the name changes — which is how you get 20260805.1, 20260805.2 within a day.

Available tokens include $(Date:...), $(Rev:.r), $(Build.BuildId), and $(SourceBranchName). Build.BuildId is an internal, immutable Run ID unique within the Azure DevOps organization, while Build.BuildNumber is the formatted run name.

Retain source and run provenance

Value	Documented meaning
`Build.SourceVersion`	The triggering version-control change; for Git, the commit ID
`Build.BuildId`	Internal, immutable Run ID unique within the organization
`Build.BuildNumber`	Customizable run name for people and downstream selectors

Pipeline-resource metadata also exposes runName, runID, runURI, and sourceCommit. That retained metadata can provide the source link; the visible artifact label does not have to embed a SHA. A semantic or calendar label can still add human meaning, but it does not replace the source/run provenance.

Reuse the producing run's artifact

Publish the artifact from its producing run, then select or download that same run-scoped artifact for later stages and environments. Pipeline resources provide a specific version picker and traceability to associated commits. Pipeline artifacts cannot be overwritten, so a rerun that regenerates an artifact needs a distinct name. For container workflows, Microsoft describes the equivalent discipline as building once and deploying the exact same tested artifact without rebuilding it.

Primary sources

Versioning pipeline artifacts

Design a versioning strategy for pipeline artifacts

Run numbers

Retain source and run provenance

Reuse the producing run's artifact