Writing
Six years from 'works on my machine' to pipelines for everyone
Jul 9, 2026
If you want to feel something about how far a team can come, look at where it started. Six years before, the build process for a platform I worked on looked like this: the packager ran on a developer’s laptop, the resulting artifact could be named just about anything, versions..what versions? These were branches being deployed right to prod and once it was out there, we didn’t even have a marker to tell which version was deployed. Test coverage sat around six percent, results were pasted into a chat channel, and “staging” was, functionally, your own machine. Gates? The gate was whether it worked on the machine of the person who built it. All of that is totally acceptable depending on the maturity level of your org but it has to grow with your org or you’ll be in a tough spot later.
With time and work across all teams, we were able to get here: CICD pipelines for everything. Builds run through a pipeline on commit, in containers, producing point-in-time artifacts you can actually roll back to. Automated testing runs in ephemeral environments and gates the artifact. There’s a staging tier with production parity, and a canary tier that lives in production with contained blast radius and high visibility. And, crucially, a developer can run locally exactly what the pipeline runs, so the pipeline stopped being a mysterious oracle that passes or fails for reasons nobody can reproduce. Devs don’t lose any control or velocity in their development workflow and the org gains visibility, accountability, predictability…lots of -ilitys, all of them good for everyone.
The hard part wasn’t the tools
It’s tempting to tell this as a tooling story, because tooling is the part you can point at. But the tools were the easy five percent. The actual work was changing what people believed was normal.
“Works on my machine” isn’t a tooling gap; it’s a culture where the developer’s laptop is the source of truth. You don’t fix that by installing a CI server. You fix it by making the pipeline’s path easier and/or better (more fun even) than the laptop’s, so that running the real build locally and letting the pipeline gate your work becomes the obvious choice rather than the imposed one. When the right way is also the easy way, adoption stops being a fight.
Doing it without a big-bang rewrite
Nobody gave us a quarter to stop and rebuild delivery from scratch, and that’s normal. This kind of change happens in the cracks: a little more coverage, one more gate, one more thing that used to be manual now reproducible. You make each step pay for itself so the momentum survives contact with the roadmap. The coverage number creeping up, the artifacts becoming discoverable, the first real canary, each one earns the next.
What I’d tell a team starting this
CI/CD maturity is a multi-year culture change measured in habits, not a tool you install on a Friday. Pick the change that makes the right way easier this week, ship it, and let it compound. The destination, pipelines for everyone with real gates and real rollbacks, looks impossibly far from six percent coverage and a laptop named “stage.” It isn’t. It’s just a lot of small, boring, correct steps in a row.