The state of things
When I got involved with the CI/CD side at diconium, Jenkins was in rough shape. Builds failed intermittently for reasons unrelated to the code. Agents went offline silently. The shared library had grown without ownership and nobody fully understood what it did. Teams had lost trust in the pipeline — they'd rerun failed builds two or three times hoping for a green, rather than investigating why it failed.
That's a bad place to be. If developers don't trust CI, they stop taking it seriously, and then you have a different problem entirely.
Making Jenkins reliable again
I was one of the engineers responsible for turning this around. The work wasn't glamorous:
- Audited all active agents — identified nodes with stale Java versions, misconfigured workspace paths, and storage that was filling up silently. Automated cleanup and set up monitoring on agent health.
- Rewrote the shared pipeline library with clear ownership, inline documentation, and a test suite for the shared steps. Previously it was a collection of scripts that had accreted over two years.
- Introduced proper ephemeral agents using Docker — builds got a clean environment every time, eliminating the "works on my agent, fails on another" class of failure.
- Set up build failure alerting that distinguished infra failures (agent died, network issue) from build failures (test red, lint error). Teams stopped re-running blindly because they could finally see why something failed.
Jenkins got reliable. Not exciting, but reliable. Builds were predictable. The flakiness rate dropped to near zero. Teams started trusting the signal again.
Why that mattered for what came next
A few months later, the decision was made to migrate to GitLab CI. Jenkins wasn't going away because it was fundamentally broken — it was going away because the team was already on GitLab for source control, and the operational overhead of maintaining a separate Jenkins fleet wasn't justified.
But the migration only went smoothly because we'd done the Jenkins work. We had a clear picture of what every pipeline did. The shared library we'd rewritten mapped almost directly to GitLab CI includes and templates. The Docker-based agent model translated naturally to GitLab's Docker executor.
I helped design and build the GitLab CI setup — the shared template structure, the rules for when pipelines trigger, the caching strategy for Maven and Docker layers. The patterns came directly from what we'd learned fixing Jenkins.
On Jenkins being "old fashioned"
It is. The configuration-as-code story is weaker, the UI is dated, the plugin ecosystem is fragile. But Jenkins being unfashionable doesn't mean the work of making it stable wasn't worth doing — or that it didn't teach anything useful.
Reliable CI is a people problem as much as a tooling problem. If developers don't trust the pipeline, the tool doesn't matter. Fixing Jenkins taught me that lesson clearly enough that I applied it from day one on every CI system I've worked on since.