Shared Pipeline Template
also called Centralised CI Template, Pipeline Inheritance
A build definition that many repositories reference rather than copy - which makes pipeline improvements propagate and makes every edit a fleet-wide deploy with no rollback for builds that already failed.
A platform team owns one CI template that 120 repositories reference by branch, so every build pulls its current HEAD. At 09:05 a change to the template's test stage is merged. Nothing is deployed, because there is nothing to deploy: each repository picks the change up on its own next build.
By 09:30 nobody in the organisation can merge anything. The template sits in required checks, so the failure is a global merge freeze - and if the platform's own repository uses the template, the revert cannot pass its own pipeline. Teams are each debugging their own change, because that is what their pipeline is telling them.
A shared template referenced at HEAD is a production dependency with no version, no rollout and no owner on call. The test-stage edit only exposed it.
Why it matters
The template model exists because copied build definitions drift: a security scan added once reaches nothing, and the estate becomes fifty independently maintained pipelines. Referencing a central template fixes propagation.
The cost of propagation is that the platform team now has a deploy channel into every repository's critical path, and it does not look like one. Their dashboard is green, their deploy succeeded, their change was not a deploy as far as any tool is concerned. Meanwhile a build that has already failed has no previous version to return to: the only recovery is to fix forward and re-run, so the queue absorbs an hour of accumulated pushes at once.
Secondary blast radius is worth naming: templates commonly carry credentials, permissions and artefact destinations, so a template change can alter what every build is allowed to do. Published postmortem write-ups of global configuration pushes describe the same mechanism: the change was data rather than a deploy, so none of the organisation's rollout controls applied to it.
Implementation patterns
- Reference immutable versions. A tag or a commit digest per repository, never a branch. This single change converts a fleet-wide push into a per-repository upgrade.
- Treat a template change as a deploy. Cohort rollout: 3 to 5 volunteer repositories for a day, then roughly 10% of the estate, then the rest - with the platform's own repository last so the revert path always works.
- Test the template against a matrix of real shapes in the estate: a monorepo, a library that publishes, a service with a database, a repository with no tests. One example repository proves nothing.
- Alert at estate level: build failure rate across all repositories, and the distribution of template versions in use. Per-repository alerting cannot see this class of failure.
- Automate the upgrade. Bump pull requests per repository plus a supported-version window, so pinning does not recreate drift.
Industry example
A superapp platform team in the mould of Grab, or any organisation past roughly a hundred repositories, reaches this shape within a year of centralising CI. The two failure modes sit on opposite ends of the same axis: scaffolded copies that never receive an improvement, and a live reference that delivers every improvement and every mistake instantly.
The practice that handles the first is automated update proposals against each repository. The practice that handles the second is versioning with cohorts. Most teams implement one and are surprised by the other, which is why the two are worth deciding together.
Failure scenarios
- Global merge freeze from a broken template in required checks, including for its own revert.
- Self-hosting deadlock, where the platform repository's pipeline depends on the template it needs to fix.
- Slow-drip breakage that arrives as a hundred tickets attributed to a hundred unrelated changes, so attribution takes longer than the fix.
- Silent behaviour change: a template that quietly stops running a stage, so builds go green faster and coverage of a whole check disappears. Nobody investigates a green build.
- Credential or permission change inherited by every build at once, which is a security event rather than an availability one.
- A long tail of pinned old versions after the correction, so the next urgent fix reaches a fraction of the estate.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Reference at HEAD | improvements land everywhere immediately - one definition to maintain | every edit is an untested fleet deploy - no rollback for failed builds - merge freeze risk |
| Pinned versions with cohort rollout | staged blast radius - a real rollback - per-repository control | version drift - bump automation and a supported window - a release process for the platform team |
| Copied templates per repository | total isolation - teams change their own builds freely | improvements reach nothing - fifty pipelines to audit - the security fix that lands once and propagates never |
When not to use it
At six repositories owned by one team. Referencing HEAD is correct: everyone notices in minutes, the fix is one commit, and the versioning machinery costs more than the failures. The threshold is not a repository count but a question - can one person fix every broken build before the next team is blocked? In practice that breaks somewhere between 15 and 30 repositories, or the first time two affected teams do not share a chat channel.
For logic that is genuinely repository-specific. A template that grows a conditional for every consumer's special case is a distributed build system with a single point of failure.
Where regulation requires per-repository evidence of what ran. Then the pinned version is the evidence, and a floating reference cannot produce it.
Interview question
Q: You own the CI template that 200 repositories reference by branch. Leadership asks for faster platform improvements; three teams have been burned by template changes this quarter. Design the change process, and tell me what you would measure to know it is working.
What a strong answer covers: immutable version references with per-repository pins · cohort rollout with the platform's own repository last, so the revert path survives · a test matrix of real repository shapes rather than one example · estate-level signals - build failure rate and version distribution - because per-repository alerting cannot see a fleet failure · automated bump pull requests and a supported window so pinning does not become drift · treating a template change as a deploy with an owner and a rollback instruction teams can apply themselves · and the honest cost: the platform team is now running a versioned product, which is weeks of work and permanent overhead.
Quick check
Quiz: Why can a bad shared-template change be harder to recover from than a bad service deploy? — A build that already failed has no previous version to roll back to, and if the template is in required checks the fix cannot be merged - including the template's own revert when the platform repository uses it.
Flashcard: Which two signals detect a fleet-wide CI template failure? — Build failure rate across all repositories and the distribution of template versions in use; per-repository alerting attributes the failure to each team's own change.