Azure DevOps – Artifacts (Part-5)

Artifacts in Azure DevOps play a crucial role in the continuous integration and continuous delivery (CI/CD) process by storing and transferring the outputs of a build process. They ensure that the same build artifacts are used across different stages of the pipeline, maintaining consistency and reliability in deployments. Here’s an in-depth look at artifacts, their usage, and how to manage them in Azure DevOps.

What Are Artifacts?

Artifacts are files or packages produced by the build process. They can include:

  • Compiled binaries
  • Configuration files
  • Packages (like .zip, .tar.gz, .nupkg)
  • Documentation
  • Log files

Artifacts are essential for:

  • Transferring build outputs to different stages of the pipeline (e.g., from build to test to deploy).
  • Ensuring consistent and reproducible deployments.
  • Facilitating rollbacks and redeployments.

Steps to Create and Use Artifacts in Azure DevOps

Step 1: Define Build Artifacts in a Build Pipeline

  1. Navigate to Pipelines:
    • Go to your Azure DevOps project.
    • Select Pipelines > Pipelines.
  2. Create a New Pipeline:
    • Click “New pipeline.”
    • Select your code repository and follow the steps to configure your pipeline.
  3. Add Build Steps:
    • Define the steps to build your application.
    • Example (YAML):
pool:
  vmImage: 'ubuntu-latest'
steps:
  - script: echo "Building the project"
  - script: mkdir $(Build.ArtifactStagingDirectory)/output
  - script: echo "Hello World" > $(Build.ArtifactStagingDirectory)/output/hello.txt

4.Publish Build Artifacts:

  • Use the PublishBuildArtifacts task to specify which files to save as artifacts.
  • Example (YAML):
steps:
  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)/output'
      ArtifactName: 'drop'

This step publishes the contents of the output directory as an artifact named drop.

Step 2: Use Artifacts in a Release Pipeline

  1. Navigate to Releases:
    • Go to Pipelines > Releases.
    • Click “New pipeline.”
  2. Define a Release Pipeline:
    • Select the artifact source (the build pipeline that produces the artifacts).
    • Configure the pipeline to use the artifacts.
  3. Add Stages to the Release Pipeline:
    • Define stages for different environments (e.g., Development, Staging, Production).
  4. Download and Use Artifacts:
    • Use the DownloadBuildArtifacts task to retrieve the artifacts.
    • Example (YAML):
stages:
  - stage: Development
    jobs:
      - job: Deploy
        steps:
          - download: current
            artifact: drop
          - script: echo "Deploying to Development"
          - script: cat $(Pipeline.Workspace)/drop/hello.txt

This stage downloads the artifact named drop and performs deployment actions.

Example Scenarios

Scenario 1: Building and Deploying a Web Application

  1. Build Pipeline:
    • Compile the web application and produce a .zip file containing the application files.
    • Example (YAML):
pool:
  vmImage: 'ubuntu-latest'
steps:
  - script: npm install
    displayName: 'Install Dependencies'
  - script: npm run build
    displayName: 'Build Application'
  - task: ArchiveFiles@2
    inputs:
      rootFolderOrFile: 'dist'
      includeRootFolder: false
      archiveType: 'zip'
      archiveFile: '$(Build.ArtifactStagingDirectory)/webapp.zip'
      replaceExistingArchive: true
  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)/webapp.zip'
      ArtifactName: 'webapp'

2.Release Pipeline:

  • Download the .zip file artifact and deploy it to an Azure App Service.
  • Example (YAML)
stages:
  - stage: Staging
    jobs:
      - job: Deploy
        steps:
          - download: current
            artifact: webapp
          - task: AzureWebApp@1
            inputs:
              azureSubscription: '<service-connection>'
              appName: '<app-name>'
              package: '$(Pipeline.Workspace)/webapp.zip'

Scenario 2: Multi-Stage Pipeline with Different Environments

  1. Build Pipeline:
    • Produce an artifact for a multi-stage pipeline.
    • Example (YAML):
trigger:
  branches:
    include:
      - main
pool:
  vmImage: 'ubuntu-latest'
stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: '5.x'
          - script: dotnet build
            displayName: 'Build the application'
          - script: dotnet test
            displayName: 'Run unit tests'
          - task: PublishBuildArtifacts@1
            inputs:
              PathtoPublish: '$(Build.ArtifactStagingDirectory)'
              ArtifactName: 'drop'

Release Pipeline:

  • Use the artifact in multiple stages for deployment to different environments.
  • Example (YAML)
stages:
  - stage: Development
    jobs:
      - job: Deploy
        steps:
          - download: current
            artifact: drop
          - script: echo "Deploying to Development"
          - script: cp -r $(Pipeline.Workspace)/drop/* /path/to/development/server

  - stage: Staging
    dependsOn: Development
    jobs:
      - job: Deploy
        steps:
          - download: current
            artifact: drop
          - script: echo "Deploying to Staging"
          - script: cp -r $(Pipeline.Workspace)/drop/* /path/to/staging/server

  - stage: Production
    dependsOn: Staging
    jobs:
      - job: Deploy
        steps:
          - download: current
            artifact: drop
          - script: echo "Deploying to Production"
          - script: cp -r $(Pipeline.Workspace)/drop/* /path/to/production/server

Related Posts

Secure supply chain: SBOM, SLSA, signing, provenance (plain English)

If you ship software today, you don’t just ship your code. You ship: That whole chain is your software supply chain. And attackers love it, because instead…

Read More

CI/CD for Cloud Apps: Build → Scan → Deploy → Rollback (a practical reference pipeline)

CI/CD sounds simple until you’re responsible for a production system and realize: This guide gives you a reference CI/CD pipeline you can adopt for most cloud apps…

Read More

Policy as Code: OPA/Rego basics + how it prevents bad infra

You know that feeling when an incident starts with a sentence like: Most “bad infra” isn’t malicious. It’s normal engineering drift:new hires, rushed PRs, copy-paste manifests, unclear…

Read More

Reusable IaC Module Design: naming, inputs/outputs, versioning (the engineer’s playbook)

Reusable IaC modules are like internal libraries: if the “API” is clean, teams move fast. If it’s messy, everyone forks it, patches it, and you end up…

Read More

GitOps explained: Argo CD vs Flux, patterns, and anti-patterns

GitOps is one of those ideas that sounds like buzzwords… until you run it for 30 days and suddenly you can’t imagine operating Kubernetes without it. Because…

Read More

Terraform vs CloudFormation vs Pulumi: which fits which team (the practical, engineer-first guide)

You’re not really choosing a tool. You’re choosing how your team will think about infrastructure for the next 2–5 years: This guide helps you decide fast, without…

Read More
guest
0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x