The CI/CD pipeline nobody maintains — why pipeline-as-code needs ownership

Every organization has one. That pipeline with 400 lines of YAML, half-commented steps, pinned action versions from 2022, and a comment that says # TODO: fix this properly above a workaround nobody understands. The pipeline that everyone knows is fragile. The pipeline that nobody touches because last time someone edited it, builds broke for an entire afternoon.

I’ve inherited that pipeline. More than once.

How pipelines rot

The pattern is always the same. Someone sets up the project, writes the CI/CD config, gets it working, and moves on. That person probably left the team eight months ago. The pipeline worked when they wrote it, so nobody had a reason to look at it again.

Then things start accumulating. A new deployment target gets added as a copy-paste of the existing stage with a few variables changed. Someone adds a caching step that doesn’t actually cache anything because the key is wrong. A security scan gets bolted on as a final stage because compliance asked for it, but nobody reads its output. The Docker build step uses an image tag that hasn’t been updated in a year.

Nobody refactors pipeline code. Nobody writes tests for pipeline logic. Nobody reviews pipeline changes with the same rigor they’d apply to application code. When a pipeline PR comes up for review, most developers skim it and approve because “it’s just YAML.” As if YAML can’t break your entire delivery process.

Pipeline-as-code is not pipeline-as-maintained-code

The industry made a big deal about moving from Jenkins UI configurations to pipelines defined in version control. And that was a genuine improvement. Having your pipeline in Git means you can see history, diff changes, and roll back when something goes wrong.

But version control enables maintenance. It doesn’t guarantee it.

A pipeline YAML file committed to Git and never touched again is no better maintained than a Jenkins job configured through a web UI and forgotten. It’s just easier to find. The file sits in your repository, technically part of your codebase, practically invisible. Nobody includes pipeline files in code quality metrics. Nobody tracks their complexity or staleness.

I’ve seen teams with thorough code review processes, comprehensive test suites, and strict linting rules for their application code. The same teams let pipeline changes merge with a single approval and no automated validation. The pipeline is somehow simultaneously the most critical part of the delivery process and the least maintained piece of code in the repo.

What ownership actually looks like

Treating pipelines as a product instead of a one-time setup changes everything. I don’t mean assigning a person to “own” the pipelines in a RACI chart. I mean giving a team the responsibility and authority to maintain, improve, and evolve your CI/CD infrastructure.

A platform team that treats pipelines as their product does specific things. They maintain a library of pipeline templates that other teams consume. They version those templates and communicate breaking changes before they land. They write tests that validate pipeline behavior, not just “does it parse” but “does it do the right thing when a stage fails.” They monitor pipeline performance and fix degradation proactively instead of waiting for developers to complain.

This doesn’t mean the platform team writes every pipeline from scratch. It means they own the patterns, the shared components, and the standards. Individual teams still configure their own pipelines, but they build on a foundation that someone maintains.

Shared templates vs. copy-paste

Almost every team I’ve worked with started by copy-pasting their CI/CD config from another project. It’s the fastest way to get started, and it works fine on day one. By day 90, you have fifteen variations of the same pipeline, each with slightly different bugs and slightly different workarounds.

One team upgrades the Docker build step. Another doesn’t. One team adds vulnerability scanning. Others keep running without it. A security fix in the base configuration needs to be applied to every copy individually. Nobody has a list of which repos use which version of the pattern. Nobody tracks it.

Template repositories solve this. When your pipelines reference a shared template, a fix to the template fixes every pipeline that uses it. Version pinning gives teams control over when they adopt changes. The platform team can ship updates, communicate what changed, and give teams a migration path.

The tradeoff is that templates are harder to write than one-off pipelines. They need to be flexible enough to handle different project types while opinionated enough to enforce standards. That tension is real. But managing fifteen diverging copies is harder in every way that matters.

The audit exercise

Here’s something I do every few months, and I’d recommend it. Go look at your oldest pipeline. Not the one you set up last week. The one that’s been running since the project started.

Count the deprecated actions or tasks. Check the versions of every tool reference. Look at the container images and check if they’re still maintained. Read through each step and ask yourself: does this still do what we think it does? Is this step even necessary? When was the last time someone verified the caching actually works?

I did this on a project last year and found a pipeline that was running a linting step against a config file that had been deleted six months earlier. The step passed because it found no files to lint. Nobody noticed because the pipeline was green.

That’s your pipeline debt. It accumulates silently, and you only discover it when something breaks in a way that takes hours to debug because the pipeline is doing things nobody expected.

A problem worth solving

Every deployment your team ships flows through your CI/CD pipeline. Every artifact, every test run, every security scan, every environment promotion. If your application code is a product, your pipeline is the factory. And nobody would run a factory with machines that haven’t been inspected or maintained since installation.

If your CI/CD is the most critical part of your delivery process and nobody owns it, that’s not a minor organizational gap. It’s a structural risk. The fix isn’t complicated. Give someone the job. Give them time to do it. Hold pipeline code to the same standards as application code.

The pipeline nobody maintains is the pipeline that will break at 2 AM on a Friday. When it does, you’ll wish someone had been maintaining it all along.