Concept and mechanism
An approved artifact should retain stable identity between QA and production. Rebuilding with unpinned dependencies can produce different bytes even when the version number matches. Publish output from the identified run and promote those contents while retaining links to code, dependencies, and tests. With Microsoft-hosted agents, each job receives a fresh VM; the previous job’s disk is not a transfer contract. Publishing and downloading Pipeline Artifacts makes that transfer explicit. Do not confuse artifacts with caches: a cache is an optimization, can miss, and is immutable for an already created key and scope. Its key should reflect relevant inputs.
Guided application
In Azure Artifacts, saving a new upstream version requires Feed and Upstream Reader, also called Collaborator, or higher. Downloading an already saved version is a different situation. A published package version is immutable; retries should not attempt to exchange bytes under the same identifier. For self-hosted agents, document software and dependencies because persistent state can hide requirements. Four available machines also do not guarantee four simultaneous jobs: confirm applicable parallel-job capacity. Finally, connect retention to recovery. Deleting a run deletes its Pipeline Artifacts; if rollback relies exclusively on that output, cleanup can remove recovery capability.
QA validated hash A; production rebuilt hash B. Promote A or validate B as different contents.
Common pitfalls
Same name as same bytes; cache as archive; assumed shared disk; retention without rollback.
Related topics: YAML, conditions, and approvals · Release, slots, and data effects
Identify, retain, and promote the contents actually validated.
Reference: Pipeline artifacts · AZ-400 objectives 2026-07-27