“Why Am I Rebuilding the Same Damn Pipeline?” — How I Finally Learned to Use Templates in Azure DevOps

Tired of copying the same YAML 7 times? Yeah, me too. Here’s how I fixed it (and my sanity).

Copy-Pasting Pipelines… You’re Wasting Brainpower

You’ve got multiple projects or microservices — and every time someone says, “Let’s spin up a new one,” your soul dies a little. Because you know it means copying the same Azure DevOps pipeline, tweaking the same 14 lines, and probably forgetting some obscure step.

Eventually, I had to ask myself: Why am I hand-building the same YAML stuff for every repo like it’s 2018?

I know, because I didn’t know how to use Azure Pipeline templates properly.

What Are Azure DevOps Pipeline Templates

Think of them like functions for YAML — reusable logic chunks. You define a pipeline once, then reference it across multiple projects, services, stages — whatever. It’s like telling Azure:

Here’s how we do builds around here. Just call it and move on.

Why it matters:

• Saves time
• Reduces bugs
• Makes onboarding devs possible
• Keeps your DevOps brain from imploding

Creating Your First Pipeline Template

Let’s walk through building a template that handles dotnet build + test + publish — and can be reused across all your projects.

Step 1: Create a Template File

Inside your repo (or a centralized infra repo), create a template/folder. Inside that, a file: dotnet-ci-template.yml:

parameters:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '7.0.x'

- script: dotnet build --configuration ${{ parameters.buildConfiguration }}
  displayName: 'Build project'

- script: dotnet test --configuration ${{ parameters.buildConfiguration }} --no-build
  displayName: 'Run tests'

Step 2: Use That Template in Your Pipeline

Now, in your actual azure-pipelines.yml file:

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: BuildAndTest
  jobs:
  - job: RunCI
    steps:
    - template: templates/dotnet-ci-template.yml
      parameters:
        buildConfiguration: 'Debug'

One line instead of 20. Multiply that by every service you own. Your YAML just lost 400 pounds.

Watch Out for These “Template Traps”

Relative Paths Will Betray You: Templates are path-sensitive. If you’re referencing from another repo or folder, double-check your file tree.

Secrets Don’t Auto-Magic: Just because you reuse a template doesn’t mean each pipeline has the same secrets or service connections. Keep environment-specific config outside the template.

Default Parameters Are Lifesavers: Templates can define default values, so you don’t have to specify buildConfiguration: ‘Release’ 17 times.

Clean Up Even Further with Template Composition

You can go even deeper by breaking things into step templates, job templates, or stage templates depending on how DRY you want to go.

• ci-steps.yml — just the build/test
• deploy-steps.yml — handles ARM templates or App Services
• notify-on-fail.yml — triggers Slack or Teams alerts

Write Once, Deploy Forever

Learning pipeline templates isn’t sexy. It’s not the thing you put on your résumé under “brag-worthy achievements.” But it’s the kind of DevOps muscle that quietly saves your team dozens of hours and stops new hires from hating your YAML graveyard.

So next time you find yourself duplicating a pipeline, stop. Turn it into a template. Thank yourself later. And maybe — just maybe — go outside for a bit. You’ve earned it.