Shared CI/CD templates used by 50+ repositories

context

I’d led the migration of source control and CI/CD onto GitLab and pushed an IaC-first approach across the estate. But pipelines had grown organically — every team carried its own near-duplicate .gitlab-ci.yml, and fixes had to be applied repo by repo. There was no single place to improve how the org ships.

constraints

• Adoption had to be earned, not mandated — teams switch when it’s obviously better, not because they’re told to.
• Teams needed real override points without forking the whole thing.
• Shared pipelines affect everyone, so changes needed versioning and a safe rollout path.

decision

Built a set of centralised, versioned GitLab CI templates and supporting CI images that repos include: rather than copy. The piece I’m happiest with is a Terraform version-agnostic image: it uses tfswitch to resolve the correct Terraform version at runtime, so every repo pins its own version from a single shared template tag — instead of maintaining a sprawl of images and tags.

outcome

• 50+ repositories now consume the shared templates.
• Widespread pipeline duplication is gone; improvements ship once, centrally.
• The version-agnostic image collapsed an image/tag sprawl down to a single shared tag teams pin against.
• A fix or improvement to a shared step now propagates to every consumer on their next version bump, instead of being hand-applied across dozens of repos.

what I’d do differently

The shared-template approach was the right tool when I built it. GitLab has since matured CI/CD Components and the CI/CD Catalog into a more structured successor — versioned, discoverable, and composable in a way included templates aren’t — and that’s the direction I’d take this next: breaking the templates into reusable components teams can find and adopt from a catalogue, rather than knowing which tag to include.