Understanding an Azure DevOps YAML Build Pipeline for .NET and Power Platform Solutions


In modern DevOps practices, Azure DevOps YAML pipelines help automate the build, validation, testing, and packaging of applications. Instead of manually compiling code, running tests, and creating deployment packages, we can define the entire process as code using YAML.

In this article, we'll walk through a real-world Azure DevOps build pipeline used for a .NET and Power Platform solution.

Complete YAML Pipeline

trigger:
- main

pool:
  vmImage: 'windows-latest'

name: RouteMasterSchedule_1.1.$(Date:yyyyMMdd)$(Rev:.r)

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: PowerPlatformToolInstaller@2
  inputs:
    DefaultVersion: true

- task: Bash@3
  displayName: Output build number
  inputs:
    targetType: 'inline'
    script: |
      echo $(Build.BuildNumber)

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: PowerShell@2
  displayName: Update the version number
  inputs:
    filePath: 'etcash.teMasterSchedule.Solution/BuildScripts/UpdateBuildVersions.ps1'

- task: VSBuild@1
  displayName: Build the solution
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: Run unit tests
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
    testAssemblyVer2: |
      **\*.UnitTests.dll
      !**\*TestAdapter.dll
      !**\obj\**

- task: BatchScript@1
  displayName: Pack the solution
  inputs:
    filename: 'etcash.teMasterSchedule.Solution/BuildScripts/pack.bat'
    workingFolder: 'etcash.teMasterSchedule.Solution/BuildScripts'

- task: CopyFiles@2
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: |
      **\*.zip
      !**\empty.zip
      **\BuildScripts\*.ps1
    TargetFolder: '$(build.artifactstagingdirectory)'
    CleanTargetFolder: true

- task: PowerPlatformChecker@2
  inputs:
    PowerPlatformSPN: 'BASE Dev'
    FilesToAnalyze: '**\*managed.zip'
    RuleSet: '0ad12332-e108-40b8-a956-9a8f95ea18c9'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

Pipeline Structure

Every Azure DevOps YAML pipeline follows a hierarchy:

Pipeline
│
├── Stage(s)
│
├── Job(s)
│
├── Step(s)
│
└── Task(s)

In this example:

  • Pipeline = Entire YAML file

  • Stage = Implicit default stage

  • Job = Implicit default job

  • Steps = All entries under steps:

  • Tasks = NuGet, Build, Test, Solution Checker, etc.

Triggering the Pipeline

trigger:
- main

The pipeline automatically runs whenever code is pushed to the main branch.

This enables Continuous Integration (CI), ensuring that every code change is validated immediately.

Build Agent

pool:
  vmImage: 'windows-latest'

Azure DevOps provisions a temporary Windows build agent containing:

  • Visual Studio

  • MSBuild

  • .NET SDK

  • PowerShell

  • NuGet

  • Power Platform tooling support

Build Naming Convention

name: RouteMasterSchedule_1.1.$(Date:yyyyMMdd)$(Rev:.r)

Produces build numbers such as:

RouteMasterSchedule_1.1.20260529.1

Benefits:

  • Easier release tracking

  • Unique build identifiers

  • Better auditability

Variables

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

Variables allow reusable configuration values.

Example:

solution: '$(solution)'

instead of repeatedly hardcoding the solution path.

Install NuGet

- task: NuGetToolInstaller@1

Installs the latest NuGet tooling on the build agent.

Required for restoring external package dependencies.

Install Power Platform Tools

- task: PowerPlatformToolInstaller@2

Installs:

  • Power Platform CLI (PAC)

  • Power Platform Build Tools

These tools are used later for solution validation and deployment activities.

Display Build Number

- task: Bash@3

echo $(Build.BuildNumber)

Outputs the generated build number into pipeline logs.

Useful for troubleshooting and deployment tracking.

Restore NuGet Packages

- task: NuGetCommand@2

Equivalent to:

nuget restore

This downloads all referenced NuGet packages before compilation.

Without this step, builds would fail because project dependencies would be missing.

Update Solution Version

- task: PowerShell@2

Runs:

UpdateBuildVersions.ps1

Typical use cases:

  • Update Assembly Version

  • Update File Version

  • Update Solution Version

  • Synchronize build numbers

This ensures that generated artifacts reflect the current build.

Build the Solution

- task: VSBuild@1

Compiles the Visual Studio solution using:

platform: Any CPU
configuration: Release

Equivalent to executing MSBuild manually.

Output includes:

  • DLLs

  • Assemblies

  • Compiled components

Run Unit Tests

- task: VSTest@2

Executes all assemblies matching:

**\*.UnitTests.dll

Benefits:

  • Validate business logic

  • Prevent regressions

  • Ensure code quality

Failed tests automatically fail the build.

Package the Solution

- task: BatchScript@1

Executes:

pack.bat

Typically used to:

  • Package Power Platform solutions

  • Create managed solution ZIP files

  • Prepare deployment artifacts

Copy Build Artifacts

- task: CopyFiles@2

Copies:

  • Solution ZIP files

  • PowerShell scripts

into the artifact staging directory.

This creates a clean deployment package.

Run Power Platform Solution Checker

- task: PowerPlatformChecker@2

Analyzes managed solutions for:

  • Performance issues

  • Security concerns

  • Unsupported customizations

  • Microsoft best practices

This step is particularly important in enterprise Power Platform implementations.

Publish Artifacts

- task: PublishBuildArtifacts@1

Publishes build outputs as:

drop

Artifacts can then be consumed by release pipelines or deployment stages.

Examples:

  • Managed Solution ZIP

  • Deployment scripts

  • Configuration files

End-to-End Pipeline Flow

Developer Pushes Code
          ↓
Pipeline Triggered
          ↓
Install Tools
          ↓
Restore NuGet Packages
          ↓
Update Versions
          ↓
Build Solution
          ↓
Run Unit Tests
          ↓
Package Solution
          ↓
Copy Artifacts
          ↓
Run Solution Checker
          ↓
Publish Artifacts

Key Benefits

This pipeline provides:

  • Continuous Integration (CI)

  • Automated Builds

  • Automated Testing

  • Power Platform Validation

  • Consistent Versioning

  • Artifact Management

  • Improved Code Quality

By automating these activities, development teams can deliver .NET and Power Platform solutions faster, with greater confidence and fewer manual errors.

Comments

Post a Comment

Popular posts from this blog

🔍 Dataverse + Azure Integration: Choosing Between Synapse Link and Microsoft Fabric

  Managing large-scale data in Microsoft Dataverse ? You're likely choosing between Azure Synapse Link and the newer Microsoft Fabric Link . Both unlock powerful analytics and reporting options—but with different trade-offs in performance, setup, and long-term cost. Let’s break it down 👇 📊 Power BI and Dataverse: Great, But With Limits Power BI uses TDS (Tabular Data Stream) to connect directly to Dataverse tables. Real-time querying works well for smaller datasets (tens of thousands of records). However, complex queries and relationships may cause timeouts after 5 minutes , making it unreliable for enterprise-scale analytics. 🔗 Azure Synapse Link: Power + Complexity ✅ Strengths: Designed for large datasets , converting Dataverse tables to CSV format for efficient querying and reporting. Highly customizable with Synapse Studio , Azure Data Lake , and Data Factory for deeper ETL/ELT capabilities. ⚠️ Watchouts: Requires technical setup : Azur...
Read more

⚡ Example: Rate Limiting in Azure API Management

  Scenario: You have a public API and want to limit each user to 5 calls per minute to prevent abuse or accidental overload. 🛡️ What is Rate Limiting? Rate limiting controls how many requests a client can make to your API within a specific time window . It helps: Prevent API abuse Protect backend systems Fairly distribute API usage 💡 Using the rate-limit-by-key Policy Azure APIM uses a policy called rate-limit-by-key . It limits requests based on a unique identifier — usually the caller's subscription key or IP address. 🔧 Example Policy (XML) Here’s how you can add this to your inbound policy : < inbound > < base /> < rate-limit-by-key calls = "5" renewal-period = "60" counter-key = "@(context.Subscription?.Key)" /> </ inbound > Explanation: Attribute Meaning calls="5" Maximum 5 calls allowed renewal-period="60" Time window of 60 seconds (1 minute...
Read more

👤 Anonymous Role in Power Pages – What It Is and When to Use It

  When building public-facing websites with Power Pages , not every visitor will be a logged-in user. Some might just be browsing, some might want to ask a question, and others might be using your portal for the very first time. So how do we allow unregistered users to interact with our portal safely ? That’s where the Anonymous Users role comes in. 🚪 Who Are Anonymous Users? Anonymous users are visitors who haven’t logged in to your Power Pages portal. They: Have not signed in May not have an account Might be visiting for the first time And here’s the best part — Power Pages automatically assigns them the “Anonymous Users” web role. You don’t have to do anything special to give it. 🔐 What Can They Do? By default, anonymous users can see pages marked as "anonymous access allowed" , but they can't create or edit data unless you let them . To let anonymous users interact with your data (e.g., submit a form), you need to: Create table permissi...
Read more