Azure pipelines templates repo

In order to centralize and standardize our CI/CD definitions, we maintain a single Common-templates repository that houses all reusable Azure Pipelines YAML templates. Project 1 and Project 2 then reference and extend these templates—avoiding duplication of pipeline code, enforcing a unified structure, and simplifying maintenance through versioned branches and Git tags. By breaking pipelines into distinct jobs, steps, and stages templates, we gain consistency and easier updates.

Objective

• Avoid duplication: All shared logic lives in a single repo, so pipelines across different projects don’t repeat the same YAML fragments.
• Version control: Branches and tags on the template repo let us release, test, or roll back template versions in a controlled manner.
• Standardization: A single source of truth defines how pipelines should be structured and parameterized.
• Faster CI: Parallel jobs run concurrently, using available agent slots to minimize the overall duration of multi‑job stages.

Common-templates Repository Layout

Rather than embedding every job, step and configuration block directly in a single azure-pipelines.yml, we break our CI definition into focused templates—for example, caching, build/program setup, test jobs, and deployment stages—and then include or extend them in each project’s pipeline. This approach delivers several key benefits:

DRY & Reuse

Common logic—like restoring NuGet/packages caches or installing language runtimes—lives in one cache.yml or program-setup.yml template. Any update (e.g. to add a new cache key or upgrade Node.js) automatically propagates to all pipelines, avoiding duplication and divergent behaviors.

Maintainability & Readability

A 600-line monolithic pipeline quickly becomes hard to navigate. By splitting into logical chunks, each template focuses on a single concern. Engineers can open build-steps.yml or test-jobs.yml in isolation, understand the flow in minutes, and troubleshoot failures without wading through unrelated stages.

Consistent Conventions

By centralizing the canonical way to configure caching or install tools, we enforce organization-wide standards—projects can’t accidentally diverge in how they restore caches or which test runner arguments they use.

Faster CI Iteration

A small change to a single template only triggers a re-run of affected steps, not the entire pipeline. Combined with parallel jobs, this modular approach lets us fine-tune and deploy pipeline changes much more quickly.

Security & Governance

Using extends templates means consumer teams cannot override critical steps (like installing security scanners) without updating the template repo—ensuring all pipelines comply with audit and compliance requirements.

By organizing our Azure Pipelines this way, we strike the right balance between flexibility (parameterized templates for project-specific needs) and control (a single source of truth for shared logic). This modular architecture is what makes our CI/CD process scalable, maintainable, and robust.

Figure 1: Common-templates repository structure

Images of the template files for our tests ( jest, cypress and a11y) and the deployment task.

Consuming Templates in Project Repos

Each consumer repo adds the templates repository as a resource and then extends a base pipeline:

Figure 2: Template extension workflow

Configure our projects scripts

To maximize reuse of our Common-templates repo, every consumer project must expose the same npm/Yarn scripts—so that the templates can unconditionally invoke, for example, npm run build, npm run test, or npm run cy:run without needing custom parameters or per-project overrides. By standardizing:

• Names and behaviors: A test script always runs unit tests; cypress:run always kicks off end-to-end checks.
• Template simplicity: Our YAML templates simply call script: npm run <name>, with no conditional logic or branching for “Project 1 vs. Project 2.”
• Onboarding speed: New repos only need to copy the standard scripts block into their package.json to immediately leverage all existing template jobs.
• Maintenance: If we update a script (e.g. adding coverage flags to test), every pipeline picks up the change automatically, since they all reference the same script name.

In short, aligning scripts across projects is what lets us write once in Common-templates and run everywhere—no project-specific YAML tweaks required.

Parallel Jobs for Faster CI

Azure Pipelines run separate jobs in a stage concurrently when dependencies are not defined. To utilize parallelism:

• Ensure you have N agent slots (hosted or self‑hosted) for N concurrent jobs.
• Configure each job without dependsOn, so they can start immediately.

Results of Project 1

Results of Project 2