What Is Build artifact in DevOps?
On This Page
Quick Definition
A build artifact is the final product of compiling and packaging source code. It is a file or collection of files that can be directly deployed or tested. For example, a .exe file for a Windows application or a .jar file for a Java application. These artifacts are stored in a repository to ensure consistent and repeatable deployments.
Commonly Confused With
A package artifact (e.g., a NuGet or npm package) is a reusable component that can be shared across multiple projects. A build artifact is the final deployable unit for a specific application. Package artifacts are stored in a package registry like Azure Artifacts, while build artifacts are typically stored in the build pipeline's drop location or Azure Artifacts as universal packages.
A NuGet package containing a logging library is a package artifact. The ZIP file of your entire web application that uses that library is a build artifact.
Binary artifact is a broader term that includes any compiled file, such as a .dll or .exe. A build artifact specifically refers to the packaged output of a build process, which may contain multiple binaries and other files. All build artifacts are binary artifacts, but not all binary artifacts are build artifacts (e.g., a binary from a third-party download).
A .dll file is a binary artifact. The entire folder containing that .dll, a .config file, and a PowerShell script, all zipped together, is a build artifact.
A container image is a specific type of build artifact that packages an application with its entire runtime environment. It is built using a Dockerfile and stored in a container registry. A traditional build artifact (like a .zip) does not include the OS-level dependencies. Container images are more portable and self-contained, but both are considered artifacts in a CI/CD pipeline.
A .NET Core app packaged as a Docker image with the runtime base image is a container image artifact. The same app packaged as a .zip file to be deployed to an Azure App Service is a build artifact.
Must Know for Exams
For the AZ-400 exam, which is the Microsoft Azure DevOps Solutions certification, understanding build artifacts is critical. The exam covers several objectives that directly involve artifacts. First, under 'Design a build strategy', you must know how to define build pipelines that produce artifacts.
This includes configuring the 'Publish build artifacts' task in Azure Pipelines, specifying artifact names and paths, and setting up retention policies to automatically delete old artifacts. Second, under 'Design a release strategy', you must understand how to consume artifacts in release pipelines, including how to link a release pipeline to multiple artifact sources (e.g.
, multiple build pipelines or Azure Container Registry). Third, under 'Implement a build strategy', you need to know how to use Azure Artifacts as a repository for packages (NuGet, npm, Maven) which are themselves a type of artifact. The exam often includes scenario questions where you must decide the best way to handle artifacts.
For example, a question might ask: 'Your team needs to deploy the same build to multiple environments, ensuring that the exact same binary is deployed to each. What should you configure?' The correct answer is to use a single build artifact and have the release pipeline consume that artifact across multiple stages.
Another common question involves troubleshooting failed releases because the build artifact is missing or expired, requiring you to set appropriate retention policies. You may also encounter questions about artifact versioning, where you need to choose a versioning scheme (e.g.
, semantic versioning with build ID) and configure conditions to skip running the release pipeline if the artifact version hasn't changed. The exam also tests your knowledge of security: artifacts should be signed and scanned for vulnerabilities. In scenario questions, you might be asked to configure a pipeline to fail if the artifact has a critical vulnerability.
Finally, the exam may ask about the difference between build artifacts and package artifacts, and when to use each. Overall, you need to not only define an artifact but also know how to create, store, version, secure, and consume it within Azure Pipelines and Azure Artifacts.
Simple Meaning
Think of building software like baking a cake. The source code is like all the raw ingredients: flour, sugar, eggs, and butter. The build process is like following the recipe to mix and bake those ingredients.
The build artifact is the finished cake, ready to be served or decorated. Just as you wouldn't serve raw ingredients to your guests, you don't deploy raw source code to production. You need to compile, test, and package it into a deployable artifact.
This artifact is a self-contained unit that includes everything the software needs to run: compiled code, libraries, configuration files, and sometimes even a runtime environment. For a web application, the artifact might be a ZIP file containing HTML, CSS, JavaScript, and server-side code. For a mobile app, it could be an APK (Android) or IPA (iOS) file.
The key is that the artifact is the result of a successful build, and it doesn't change until the next build. This ensures that what you test in staging is exactly what you deploy to production, eliminating the classic 'it works on my machine' problem. In modern DevOps, these artifacts are versioned and stored in a central repository like Azure Artifacts or Nexus, so that any previous version can be easily retrieved for rollback or audit purposes.
Full Technical Definition
In the context of software development and DevOps, a build artifact is the output of a compilation and packaging process, typically produced by a continuous integration (CI) pipeline. The process begins when a developer commits code to a version control system like Git. A CI server, such as Azure DevOps, Jenkins, or GitHub Actions, detects the change and triggers a build pipeline.
The pipeline retrieves the source code, restores dependencies (e.g., NuGet packages, npm modules), compiles the code using a compiler appropriate for the language (e.g., MSBuild for C#, javac for Java, webpack for JavaScript), runs unit tests, and if successful, packages the output into an artifact.
Artifacts can take many forms: executable binaries (.exe, .dll), library packages (.jar, .nupkg, .whl), container images (Docker images pushed to a registry), web deployment packages (.
zip, .war), or installer files (.msi). The artifact is given a unique version number (e.g., 1.2.3.4567) and is published to an artifact repository. Azure DevOps uses Azure Artifacts as its native repository, which supports multiple feed types for NuGet, npm, Maven, Python, and Universal packages.
The artifact is also often signed with a digital signature to verify its integrity and authenticity. In a full CI/CD setup, the build artifact is then consumed by a release pipeline, which retrieves it from the repository and deploys it to various environments (dev, test, staging, production). The use of immutable artifacts is a core tenet of DevOps: once an artifact is built, it is never modified.
If a change is needed, a new build is triggered, producing a new artifact with a new version. This ensures traceability and repeatability. In the AZ-400 exam, you will be expected to understand how to configure build pipelines to produce and publish artifacts, how to set up retention policies, and how to consume artifacts in release pipelines.
Real-Life Example
Imagine you are a caterer preparing meals for a large event. Your source code is the recipe book and your kitchen is the development environment. The build process is the actual cooking: you gather ingredients (dependencies), chop vegetables (compile code), and cook each dish (run tests).
The build artifact is the final plated meal, complete with garnishes, ready to be served. You wouldn't bring a raw chicken and a bag of flour to the event and assemble the meal there. That would be risky and time-consuming.
Instead, you prepare everything in your controlled kitchen, test the taste (unit tests), and package each meal in a serving container (artifact). Each meal is labeled with a date and batch number (version number). You store these meals in a temperature-controlled transport container (artifact repository).
When you arrive at the event, you simply take the meals out and serve them. If a guest wants the same meal as last year, you can check your records (artifact repository) and find that exact batch. This is exactly how build artifacts work in software: they allow you to separate the build process from the deployment process, ensuring consistency and reliability.
Just as you wouldn't let a guest into the kitchen during cooking, you don't want deployment environments to build code. Everything is pre-built and stored as an artifact.
Why This Term Matters
Build artifacts are a cornerstone of modern DevOps because they enable reliable, repeatable, and auditable software releases. Without them, each deployment environment would need to compile the code from scratch, leading to the 'it works on my machine' problem. By standardizing on immutable artifacts, teams can be confident that the code tested in staging is identical to the code deployed to production.
This drastically reduces the risk of environment-specific bugs. Artifacts also facilitate rollback: if a new deployment causes issues, operations can simply redeploy the previous version of the artifact from the repository, without needing to recompile the old code. In a compliance-required industry (finance, healthcare), artifacts serve as an audit trail, proving exactly what code was deployed and when.
From a performance perspective, pre-built artifacts speed up deployments because the heavy lifting of compilation and testing is done only once during the CI pipeline, not repeated in every environment. Artifacts also enable parallel work: while the release team deploys version 1.0 to staging, the development team can already be building version 1.
1. The isolation of build and release stages is a fundamental DevOps principle. In practice, a team using Azure DevOps will configure a build pipeline that produces a web deployment package, publishes it as an artifact, and then a separate release pipeline picks up that artifact and deploys it to Azure App Service.
This separation not only improves speed but also clarifies responsibilities: developers own the build pipeline and produce artifacts, while operations or release managers own the release pipeline and consume artifacts. This concept directly maps to the AZ-400 exam objectives under 'Design a release strategy' and 'Implement a build strategy'.
How It Appears in Exam Questions
In the AZ-400 exam, questions about build artifacts appear in multiple formats. Scenario-based questions are the most common. For example: 'A company uses Azure Pipelines for CI/CD.
The release pipeline fails because it cannot find the build artifact. What should the DevOps engineer check first?' The answer would be: 'Check the retention policies on the build artifact to ensure it hasn't been deleted before the release pipeline runs.'
Another scenario: 'Your team wants to deploy the same build to staging and production environments. How should you configure the pipeline?' The correct answer is to use a single build pipeline that publishes one artifact, and a release pipeline with multiple stages that all reference that same artifact.
Configuration questions ask you to specify the correct YAML syntax or Azure DevOps UI settings. For instance: 'Which task should you add to a build pipeline to make the build output available to a release pipeline?' Answer: 'Publish Build Artifacts task.'
You may also get troubleshooting questions: 'A build succeeds, but the release pipeline fails with an error that the artifact is not found. What is the most likely cause?' Options might include: (A) The artifact name in the release pipeline does not match the artifact name in the build pipeline; (B) The build is not complete; (C) The agent pool is offline; (D) The repository is empty.
The correct answer is A, because the release pipeline looks for the artifact by name, and a mismatch prevents it from being found. Another common question pattern is comparing artifact types: 'Which type of artifact should you use to store a compiled .NET application?'
Answer: 'Build artifact (drop)'. Or: 'Which artifact repository supports NuGet packages?' Answer: 'Azure Artifacts.' You might also be asked about security: 'You need to ensure that build artifacts are not tampered with after creation.
What should you do?' Answer: 'Sign the artifact with a digital certificate.' Questions can also involve multi-stage pipelines: 'You have a multi-stage YAML pipeline. How do you make artifacts available from one stage to another?'
Answer: 'Use the 'publish' and 'download' keywords in the YAML file.' Finally, exam questions may test your understanding of artifact retention: 'You want to keep the last 10 successful builds for audit purposes. How should you configure retention?'
Answer: 'Set a retention policy on the build pipeline to keep a maximum of 10 and a minimum of 1 build.'
Study AZ-400
Test your understanding with exam-style practice questions.
Example Scenario
Imagine you are a DevOps engineer at a company that develops a mobile app called 'FitTracker.' Your development team builds the app daily. Your CI/CD pipeline is set up in Azure DevOps.
Every morning, a developer pushes code changes to the master branch. This triggers a build pipeline. The pipeline does the following: it pulls the latest code, restores NuGet packages, compiles the C# backend, uses a webpack build for the React frontend, runs unit tests, and finally runs a task called 'Publish Build Artifacts.'
This task creates a ZIP file named 'FitTracker-1.2.3.zip' containing the compiled backend DLLs, the frontend static files, and a configuration file. This ZIP file is stored in Azure Pipelines and is given a retention policy of 30 days.
Meanwhile, the release pipeline is configured to deploy to three environments: Dev, QA, and Production. The release pipeline picks up the exact same ZIP file for each environment. On one occasion, the QA team finds a bug in the new build.
The release manager decides not to deploy that artifact to production. Instead, they go to Azure Pipelines, locate the previous successful build (1.2.2), and manually trigger a deployment using that older artifact.
This is possible because artifacts are immutable and versioned. If the build artifact had never been created, the release pipeline would need to rebuild the code from the old commit, but that could introduce minor differences due to updated dependencies or tooling versions. By using a stored artifact, the rollback is clean and reliable.
This scenario demonstrates exactly why artifacts are essential: they decouple build from release, enable consistent deployments, and simplify rollback. In the AZ-400 exam, you might be asked what to do if a release fails due to a missing artifact, and the correct answer would involve checking retention policies and artifact names, exactly as illustrated here.
Common Mistakes
Thinking that the build artifact is the same as the source code repository.
The source code repository contains raw, uncompiled code and is not directly deployable. The build artifact is the compiled and packaged output. Deploying from the repository would introduce inconsistencies because each environment would compile differently.
Always deploy from a build artifact, not from source code. The build pipeline should produce an artifact, and the release pipeline should consume that artifact.
Not versioning build artifacts properly or overwriting them.
If you overwrite an artifact, you lose the ability to rollback to a previous version. This defeats the purpose of deterministic releases and audit trails.
Use unique version numbers for each build (e.g., using the build ID or semantic versioning). Never overwrite an existing artifact. Configure the pipeline to always create a new version.
Setting retention policies too short so that artifacts are deleted before releases complete.
If a release pipeline takes longer to run (e.g., multiple stages over several days), the artifact might be deleted before the final stage runs, causing a failure.
Set retention policies to keep artifacts for at least as long as the longest release pipeline takes, plus a buffer. Also consider using minimum and maximum retention numbers.
Confusing build artifacts with package artifacts (like NuGet or npm packages).
Build artifacts are typically the output of a full application build (e.g., a web deploy package). Package artifacts are reusable libraries published to a package registry. They serve different purposes and require different pipeline configurations.
Know the difference: build artifacts are for deploying the whole application; package artifacts are for sharing dependencies. In Azure Pipelines, use 'Publish Build Artifacts' for the former and 'NuGet push' for the latter.
Assuming that artifacts are only for binary files and cannot include scripts or configuration files.
Artifacts can include any files you need for deployment, including PowerShell scripts, JSON configuration files, or even documentation. The key is that they are packaged together and immutable.
Include all necessary files in the artifact. In the build pipeline, specify the correct path to include scripts, configurations, and any other deployable assets.
Exam Trap — Don't Get Fooled
{"trap":"The exam may present a scenario where a build artifact is published, but the release pipeline fails because the artifact cannot be downloaded. The trap option is 'The build agent is offline' or 'The source code has a compilation error.'","why_learners_choose_it":"Learners often think that if a release fails, it must be a network issue or a code problem, because those are common causes.
They might not immediately think of retention policies or artifact name mismatches.","how_to_avoid_it":"Always check the artifact name and retention policy first. If the build succeeded, the artifact was created.
The most likely issue is that the release pipeline is looking for an artifact with a different name or that the artifact was deleted by a retention policy. In the exam, look for clues about retention policies or artifact aliases. If the question mentions 'the build succeeded' and 'the release fails,' the answer is usually related to artifact naming or retention."
Step-by-Step Breakdown
Code Commit
A developer pushes changes to the version control repository (e.g., Git in Azure Repos). This triggers the CI pipeline.
CI Pipeline Trigger
Azure Pipelines detects the commit and starts the build pipeline as defined in the YAML file or classic editor. The pipeline runs on a Microsoft-hosted or self-hosted agent.
Restore Dependencies
The pipeline restores external dependencies needed for compilation. For .NET, this is a 'dotnet restore' or 'NuGet restore' step. For Node.js, it's 'npm install'. This ensures all libraries are available.
Compilation and Testing
The pipeline compiles the source code using build commands like 'dotnet build' or 'msbuild'. Then it runs automated unit tests. If any step fails, the pipeline stops and no artifact is produced.
Package the Artifact
After successful compilation and tests, the pipeline uses a task (e.g., 'Publish Build Artifacts') to copy the output files (binaries, configuration files, scripts) into a single deployable unit, often a ZIP file or a folder structure. The artifact is given a name and version.
Publish to Repository
The artifact is uploaded to Azure Pipelines' built-in artifact storage or to Azure Artifacts. It is stored with metadata like build number, commit ID, and timestamp. Retention policies are applied to control how long the artifact is kept.
Consume in Release Pipeline
The release pipeline retrieves the artifact from the repository. It downloads the exact same files for each deployment stage (dev, test, prod). The artifact is then extracted and deployed to the target environment.
Practical Mini-Lesson
In real-world DevOps, managing build artifacts goes far beyond just creating a ZIP file. As an Azure DevOps professional, you need to design a robust artifact strategy. First, decide on an artifact format.
For .NET applications, a web deployment package (.zip) is standard. For containerized applications, you build and push a Docker image to a container registry like Azure Container Registry (ACR).
Both are artifacts, but they require different pipeline tasks. When you publish a build artifact in Azure Pipelines, you need to specify a name (e.g., 'drop') and a path to the files.
This name is used in the release pipeline to download the artifact. A common mistake is to hardcode the artifact name in the release pipeline, and then when the build pipeline changes the name, the release breaks. Instead, use pipeline variables to make the artifact name configurable.
Retention policies are critical: you must balance storage cost with audit requirements. For example, you might keep the last 10 builds for all branches, but keep all builds for the 'main' branch for 90 days for compliance. You can configure separate retention policies for different branches in the pipeline settings.
Another practical consideration is artifact size. Large artifacts can slow down deployments. Consider using incremental builds or excluding unnecessary files. For example, exclude 'node_modules' if the frontend is compiled, as only the bundled output is needed.
For Azure Web Apps, you can use 'Run from Package' feature, which allows you to deploy a ZIP file directly without extracting it, improving performance. Security is also vital: sign your artifacts with a code signing certificate to prevent tampering. Azure Key Vault can be used to store the certificate and integrate with the pipeline.
Also, scan artifacts for vulnerabilities using tools like OWASP ZAP or Microsoft Defender for Cloud. In the pipeline, you can add a task to fail the build if a critical vulnerability is found. Finally, versioning: use semantic versioning (major.
minor.patch) combined with the build ID (e.g., 1.2.3.20250320.1) to ensure uniqueness. This allows you to trace any artifact back to the exact build that produced it. All these practices are directly relevant to the AZ-400 exam, which expects you to design and implement a comprehensive artifact management strategy.
Memory Tip
Think of a build artifact as an orange: you can't serve the tree (source code), you must squeeze it into juice (artifact) first. The juice is ready to drink (deploy) and you can store multiple bottles (versions) in the fridge (repository).
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
An AAAA record is a DNS record that maps a domain name to an IPv6 address, allowing devices to find each other over the internet using the newer IP addressing system.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
Frequently Asked Questions
What is the difference between a build artifact and a release artifact?
They are essentially the same thing. The term 'build artifact' refers to the output of a build pipeline. The term 'release artifact' is often used in the context of a release pipeline to refer to the same artifact being deployed. In Azure DevOps, you build an artifact and then release it.
Can I create multiple artifacts from one build pipeline?
Yes, you can. For example, you could produce one artifact for the backend and another for the frontend. However, it is often simpler to create a single artifact that contains everything needed for deployment. Use separate artifacts only if different teams consume them differently.
How do I secure build artifacts?
You can sign artifacts with a digital certificate to ensure integrity. You can also set permissions on the artifact feed in Azure Artifacts to control who can read or modify artifacts. Scan artifacts for vulnerabilities in the pipeline.
What happens if a build artifact is deleted before the release pipeline runs?
The release will fail with an error that the artifact is not found. To prevent this, set appropriate retention policies that keep artifacts long enough for all release stages to complete. You can also set a minimum number of builds to retain.
Should I include test results in the build artifact?
Generally no. Test results are usually separate from the deployable artifact. The artifact should contain only the files needed to run the application. Test reports are better stored in the pipeline itself or in a separate test results repository.
What is a 'drop' in Azure Pipelines?
A 'drop' is the default folder name where build artifacts are published when using the classic editor. It is essentially a placeholder. In YAML pipelines, you can name it anything. The term is still commonly used to refer to the build artifact output location.
Summary
A build artifact is the immutable, versioned output of a successful CI build, containing all the files necessary to deploy an application. It decouples the build process from the release process, enabling consistent deployments, easy rollbacks, and clear audit trails. In the context of the AZ-400 exam, you must understand how to create, publish, version, and consume artifacts within Azure Pipelines.
Common exam scenarios involve troubleshooting missing artifacts due to retention policy issues, configuring multi-stage pipelines to share artifacts, and securing artifacts with signing and scanning. By mastering build artifacts, you ensure that your DevOps pipeline is reliable and that every deployment uses an identical, traceable package. This is not just a theoretical concept but a practical necessity for any professional managing Azure DevOps.
The key takeaway is: always deploy from an artifact, never from source code. Remember, a build artifact is the single source of truth for what will be released to production.