Azure DevOps – Microsoft Hosted and Self-hosted Agents (Part-3)

In Azure DevOps, agents are the workers that run your build and release jobs. There are two types of agents: Microsoft-hosted agents and self-hosted agents. Here’s a detailed explanation with examples and steps:

Microsoft-hosted Agents

Why: Microsoft-hosted agents are provided by Azure DevOps and run on Microsoft’s infrastructure. They are convenient because they require no setup and are always up-to-date with the latest tools and updates.

Steps:

  1. Create a New Pipeline:
    • Go to your Azure DevOps project.
    • Navigate to Pipelines > Pipelines and click on “New pipeline.”
  2. Select the Code Repository:
    • Choose where your code is stored (e.g., Azure Repos, GitHub).
  3. Configure the Pipeline:
    • Select a template or start from scratch.
    • Define the pipeline steps in a YAML file or use the visual designer.
  4. Use Microsoft-hosted Agents:
    • By default, the pipeline uses Microsoft-hosted agents.
    • Example YAML:yamlCopy codepool: vmImage: 'ubuntu-latest' steps: - script: echo Hello, world! displayName: 'Run a one-line script'
  5. Run the Pipeline:
    • Save and run the pipeline.
    • The pipeline will use a Microsoft-hosted agent to execute the steps.

Example: You want to compile a .NET application. The pipeline YAML might look like this:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'windows-latest'

steps:
  - task: UseDotNet@2
    inputs:
      packageType: 'sdk'
      version: '5.x'
  - script: dotnet build
    displayName: 'Build the application'
  • When you run this pipeline, it uses a Microsoft-hosted agent with the windows-latest image to build your .NET application.

Self-hosted Agents

Why: Self-hosted agents are managed by you on your own infrastructure. This is useful if you need specific software configurations, more control over the build environment, or if you want to avoid the limitations of Microsoft-hosted agents (e.g., build time limits).

Steps:

  1. Set Up a Self-hosted Agent:
    • Go to your Azure DevOps project.
    • Navigate to Project Settings > Agent pools.
    • Click on “New agent” to download the agent package.
  2. Install the Agent:
    • Extract the downloaded package on your server.
    • Run the configuration script and provide the necessary information (server URL, agent pool, personal access token).
  3. Register the Agent:
    • The agent will register itself with Azure DevOps and appear in the agent pool.
  4. Configure the Pipeline to Use the Self-hosted Agent:
    • Modify your pipeline YAML to use your self-hosted agent pool.
    • Example YAML:
pool:
  name: 'Self-hosted'
steps:
  - script: echo Hello, self-hosted world!
    displayName: 'Run a one-line script'
  1. Run the Pipeline:
    • Save and run the pipeline.
    • The pipeline will use your self-hosted agent to execute the steps.

Example: You need to run a build on a machine with specific hardware or software. After setting up the self-hosted agent, your pipeline YAML might look like this:

trigger:
  branches:
    include:
      - main

pool:
  name: 'Self-hosted'

steps:
  - script: echo Running on a self-hosted agent
    displayName: 'Message'
  - script: ./build.sh
    displayName: 'Build the application'
  • When you run this pipeline, it uses your self-hosted agent to execute the build script build.sh.

Live Environment and Flow

  1. Microsoft-hosted Agent Flow:
    • Developer commits code to the repository.
    • Pipeline triggers automatically.
    • Microsoft-hosted agent picks up the job, sets up the environment, runs the build/test/deploy steps.
    • Results are reported back to Azure DevOps.
  2. Self-hosted Agent Flow:
    • Developer commits code to the repository.
    • Pipeline triggers automatically.
    • Self-hosted agent picks up the job from the configured server, runs the build/test/deploy steps using the custom environment.
    • Results are reported back to Azure DevOps.

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