Coming Soon ..

← blog

Treat your pipeline templates as a product

5 August 2026 · OpsUnity

Copy-pasted pipeline YAML drifts the moment it is duplicated. A versioned template library fixes it — provided you treat consumers as customers.

The second repository is where CI/CD standards go to die. Someone copies the first pipeline, changes three values, and now there are two definitions of how the organisation builds software. By the tenth repository nobody can answer what the build process is, because there are ten answers.

What a template library needs to succeed

  • Semantic versioning with a real changelog — consumers need to know whether an upgrade is safe
  • Consumers pinned to released tags, never to a branch; a floating reference means a merge in the template repository can break unrelated production pipelines
  • Composition in layers — steps into jobs into stages — so teams can adopt a piece without taking everything
  • Sensible defaults, so the minimal usage is genuinely minimal
  • A migration note whenever behaviour changes, written for someone who did not attend the design discussion

The failure we see most

Standards documented but not enforced. We audited an estate where the rule was 'pin to a tag' and not a single consumer complied — including one production pipeline pinned to a feature branch that could have been deleted at any time.

The fix was not a better document. It was a validation step that fails the build when a reference is not a tag. If a standard matters, a pipeline should enforce it; anything else is a suggestion.