One thing I've noticed across different projects is that CI pipelines almost never get smaller.
Application code changes constantly. Old abstractions disappear. Dependencies are replaced. Entire features get deleted. The pipeline, meanwhile, quietly accumulates history.
A flaky test appears, so someone adds a retry. A deployment fails because of a missing check, so another validation step gets added. A production incident leads to a custom script that everyone agrees is necessary. Months later the incident is long forgotten, but the script is still there. Nobody wants to be responsible for removing it.
The result isn't necessarily a bad pipeline. In fact, many of those additions exist for good reasons. The problem starts when the reasons disappear while the implementation stays.
I've started treating CI configuration like any other piece of code. If I can't explain why a particular job exists, that's worth investigating. Sometimes the answer is a critical production lesson. Sometimes it's just leftover caution from a problem that no longer exists.
Neither outcome is bad. The important part is knowing which one you're looking at.
There's also an interesting psychological effect. Application code gets reviewed constantly because everyone sees it. Pipeline configuration often becomes background noise. It works, so nobody asks questions. Until one day a build takes twice as long as it used to, or a deployment fails because two old assumptions started conflicting.
I don't think every pipeline should become smaller.
I do think every step should have a reason that someone on the team can still explain. If the explanation starts with "I think this was added a long time ago...", that might be enough reason to take another look.
Top comments (0)