Loading...

Azure Quick Links

Azure Cloud Projects

Azure DevOps IaC Pipeline

Deploy and manage Azure resources using IaC with Azure DevOps. Learn to run pipelines, use Bicep templates, and manage updates via pull requests.

This project demonstrates deploying and managing Azure resources using IaC with Azure DevOps. You will work with YAML pipelines and Bicep templates to automate provisioning of resource groups, VNets, and VMs.

Key steps include:

  • Understanding project files, setting up a self-hosted agent, configuring service connections, running deployment pipelines, and managing changes through pull requests.
  • This hands-on project highlights automated deployments, secure configurations, and professional DevOps workflows.

The project consists of three files:

The YAML pipeline automatically uses these two Bicep files to create the Resource Group first, extract its output values, and then deploy the VNet and VM into that Resource Group. This allows a fully automated, repeatable, and parameter-driven deployment.

*

Task Details

1. Understand project files: iac-demo-pipeline.yaml, iac-demo-rg.bicep, iac-demo-vm.bicep.

2. Set up a self-hosted agent in Azure DevOps to run your deployments.

3. Upload the files and run the YAML pipeline to deploy resources.

4. Create service connection.

4. Create and run a pipeline in Azure DevOps to deploy resources by using the YAML along with the two Bicep templates.

5. Make changes to your deployment through the IaC DevOps portal and create a pull request.

*

Steps

Understand project files.

1. Pipeline File—iac-demo-pipeline.yaml

This YAML file defines the Azure DevOps pipeline that automates your entire infrastructure deployment. It does two things:

Deploys the Resource Group using a subscription-level Bicep file (iac-demo-rg.bicep).
The pipeline captures the outputs (resource group name, location, tags) and stores them as variables.

Deploys the VNet and VM into that resource group using the second Bicep file (iac-demo-vm.bicep).
The pipeline uses the variables from the first deployment to ensure everything is consistent and fully automated.

This file connects DevOps → Azure → your Bicep templates and acts as the “controller” for the whole deployment.

Copy iac-demo-pipeline.yaml content

Note: Scroll down to locate the iac-demo-vm.bicep file string.

*

2. Resource Group Bicep File—iac-demo-rg.bicep

This Bicep template runs at the subscription scope and is responsible for creating the resource group that will hold all other resources. It defines:

Parameters for the resource group name (rg-iac-01), location, and tags

A Resource Group resource using Microsoft.Resources/resourceGroups

Outputs (name, location, tags) that the pipeline will capture and pass to the next deployment

These outputs are essential because the VM and VNet deployment uses them to ensure all resources are created in the correct resource group with consistent tags.

Copy iac-demo-rg.bicep content 

*

3. VM + VNet Bicep File — iac-demo-vm.bicep

This Bicep template deploys all required compute and networking resources inside the resource group created earlier. It takes parameters (location, VM name, tags, sizes, VNet settings) passed from the pipeline and builds:

  • A Virtual Network (VNet) with an address space and one subnet
  • A Public IP address for external connectivity
  • A Network Interface (NIC) that links the VM to the VNet

A Virtual Machine (VM) running Ubuntu, with:

  • OS disk
  • A 1 TB data disk
  • Admin credentials
  • VM size and storage type

This file contains the core infrastructure logic, defining how the VM and networking components are created and connected. The pipeline uses this template after the resource group is created to complete the full environment deployment.

Copy iac-demo-vm.bicep content

*

Set up a self-hosted agent in Azure DevOps to run your deployments.

1. Navigate to Your Project in Azure DevOps https://dev.azure.com/

  • Open Azure DevOps in your browser.
  • Select your organization from the list.
  • Click on the project you want to work on to open its dashboard.

*

2. Open Project Settings.

  • In your Azure DevOps project, scroll to the bottom-left corner of the page.
  • Click on Project Settings to access configuration options for your project.

*

3. Choose Your Agent Pool.

To use your own machine, select the Default (Self-Hosted) Agent.

If you want to use Microsoft-managed infrastructure, select Azure Pipelines, which provides a Microsoft-hosted agent.

*

4. Add a Self-Hosted Agent Pool.

  • Click “Add pool” to create a new agent pool.
  • Under Pool type, select Self-hosted.
  • Provide a name for your agent pool.
  • Check “Grant access permissions to all pipelines” to allow all pipelines in the project to use this pool.

Note: An agent pool provides the machines (agents) that Azure DevOps pipelines use to run builds, tests, and deployments. Without a pool, your pipelines cannot execute.

*

5. Click on the self-hosted agent pool you just created to view its details and manage agents.

*

6. Add a New Agent.

  • Click “New agent” within your self-hosted agent pool.
  • Download the agent package for your operating system (e.g., Windows, Linux, macOS).

*

7. Initialize the Agent Connection.
Unzip the downloaded agent with: tar zxvf filename.gz

*

8. Open a terminal on your Linux system.

Run the configuration script: ./config.sh

When prompted, provide:

  • Server URL – the URL of your Azure DevOps organization.
  • Personal Access Token (PAT) – generated earlier. (Refer to this guide on how to generate a PAT token.)
  • Agent pool – select the pool you created.

Accept the default settings for the remaining prompts, unless you have custom requirements.

*

9. Start the Self-Hosted Agent.

In the agent folder, run the following command to start the agent and listen for pipeline requests: ./run.sh

The agent will now connect to Azure DevOps and be ready to execute jobs from your pipelines.

*

Note: To install Azure CLI on Kali Linux use these steps:

*

*

10. Confirm that the agent is online in DevOps portal.

*

Now it's ready to run pipelines.
With your self-hosted agent running and connected, you are now ready to execute Azure DevOps pipelines.
Pipelines will use your self-hosted agent to perform builds, tests, and deployments.

Upload the files and run the YAML pipeline to deploy resources.

1. Create a new project in Azure DevOps and name it IAC.

*

*

2. Set up a repository and initialize the main branch within the project to store your files.

*

3. Create a folder named /bicep in your repository.

*

4. Create a new folder named bicep and a new file named demo, then click Create.

Note: You must add some text to the file before committing the change.

*

5. Upload the three files:

iac-demo-pipeline.yaml — the Azure DevOps pipeline.

iac-demo-rg.bicep — subscription-level Bicep template for resource group creation.

iac-demo-vm.bicep — resource-group-level Bicep template for deploying the virtual network and virtual machine.

Note: Place the Bicep files (iac-demo-rg.bicep and iac-demo-vm.bicep) inside the /bicep folder, and keep the YAML pipeline file in the root or a separate /pipelines folder. Make sure the file paths in the pipeline match this structure.

*

*

*

6. Create a folder named "pipelines" in your repository to store the YAML pipeline file, and upload iac-demo-pipeline.yaml to this folder.

Note: Follow the same steps you used to create the /bicep folder and add a file.

*

Create a service connection.

1. Open Your Project Settings.

  • Navigate to Organization → Select your project → Project settings.

Note: Service connections are project-specific, meaning each project requires its own service connection configuration.

*

2. Create a New Service Connection.

  • In Project Settings, open the Service connections tab.
  • Select Azure Resource Manager as the connection type.
  • Click Next to continue with the configuration.

*

3. Authenticate to Azure.

  • After clicking Next, an Azure authentication window will appear.
  • Sign in using your Azure portal credentials to authorize the service connection.

*

4. Configure the Service Connection Details.

  • Select your Azure subscription from the list.
  • Provide a name for the service connection to easily identify it later.

*

5. Make a note of the service connection ID for future reference.

Create and run a pipeline in Azure DevOps to deploy resources by using the YAML along with the two Bicep templates.

1. Go to Pipelines → Create Pipeline → Azure Repos Git (YAML), select your project, choose Existing Azure Pipelines YAML file, and enter the path to your YAML pipeline file and click continue.

 

2. Review your parameters.

 

3. Run the pipeline.

 

4. Assign permission to the pipeline.

Click View then Permit.

 

 

5. Confirm that the deployment was completed successfully.

 

6. Go to the Azure portal and confirm your deployment.

 

Make changes to your deployment through the IaC DevOps portal and create a pull request.

With Azure DevOps and IaC, we can deploy resources and make precise configuration changes that aren’t possible or easily manageable through the Azure Portal.

This is one of the biggest advantages of using Infrastructure as Code (IaC) with Azure DevOps.

Change the tag values.

Go to your files and change the tag values in iac-demo-rg.bicep:

  •  costCenter: 'CC-5678'
  •  businessUnit: 'Human Resources'

Click Commit to save the changes.

 

2. In commit page fill up:

  • Comment : Updated iac-demo-rg.bicep
  • Branch name: updated-tags
  • Create pull request: selected

Note:

Benefits of using a separate branch:

  • Keeps the main branch stable.
  • Allows you to work without breaking other deployments.
  • Supports code review and collaboration.

Reasons for creating a Pull Request (PR):

  • Code review: Team members can review your Bicep changes and suggest improvements.
  • Approval workflow: Some repositories require approvals before changes reach production.
  • Audit trail: The PR documents what changes were made (e.g., updated tags) and why.
  • CI/CD triggers: In Azure DevOps, a PR can trigger pipeline validation, like deploying to a test environment before production.

 

3. Click Create to create a new pull request.

 

4. Click Complete.

Note: On this page you can review code changes, manage reviewers, link work items, and approve or complete the merge for the proposed updates in the pull request.

 

5. On "Complete pull request" page choose Merge and click "Complete merge"

 

 

6. Go back to pipelines and run the pipeline again.

 

7. Go to the Azure portal and confirm that the tag values have been changed successfully.

 

Conclusion

In Azure DevOps, when you manage a deployment via IaC (Bicep, ARM templates, Terraform, etc.), the types of changes you can make depend on what your pipeline and templates support, but generally you can do the following:

Infrastructure Changes

  • Add or remove resources: e.g., add a storage account, delete a VM, create a new subnet.
  • Update resource properties: e.g., change VM size, update network security rules, modify disk types.
  • Scale resources: e.g., increase VM count in a scale set, adjust App Service plan size.

Configuration Changes

  • Environment variables/parameters: change values for templates without modifying the template file (via pipeline variables or parameter files).
  • Secrets/credentials: update passwords, keys, or service principals (often via Azure Key Vault).
  • Tags & metadata: update resource tags for cost tracking or organization.

Pipeline/Deployment Settings

  • Pipeline triggers: modify when your deployment runs (on commit, schedule, manual).
  • Approvals & checks: add manual approval steps before applying changes.
  • Variable groups: update values used by the pipeline for deployment.

Template / Code Changes

  • Modify IaC templates: change VM sizes, disk types, or add resources in Bicep/ARM/Terraform.
  • Update parameter files, e.g., switch locations, resource group names, or storage SKUs.
  • Add modules or linked templates for reusable components.

Important:

Any change must still be compatible with Azure (e.g., cannot set invalid disk types like Standard_HDD).

Safe approach: test changes in a dev/test resource group before applying to production.

*

Written by Kirill.A - Azure & Cybersecurity Consultant at AntusNet

➤ Want more? Browse all our Azure implementation guides.

Need help implementing secure Azure solutions?

Contact us for a free consultation.

    error: Content is protected !!