Once built a CI/CD workflow for a team. Standard stuff: took their template, improved it - proper Docker layers, minimalism, build ahead instead of on container startup.
Done. Deployed to dev and prod. Works. Perfect.
2 days later: “Production is broken.”
Dug in. Found it quickly: package.json had a dependency tagged :dev. For production.
Someone put a dev version of a third-party library in prod. Something changed in that version - either a bug or breaking changes. Prod is down.
Lesson: I built the pipeline right for myself. But forgot about the team.
I did everything correctly. On my end. But forgot the main thing: people aren’t perfect. Someone will use :dev in prod. Someone will forget to pin a version. Someone doesn’t even know you shouldn’t do that.
You know how “don’t commit passwords to git”? Same here: don’t use dev library versions in prod. But knowing the rule isn’t enough - you need a system that won’t let you break it accidentally.
Before, I built “correct” CI/CD on my end. Pipeline works? ✅ My job done.
Now - reliable. With automatic checks not just for my code, but for typical team mistakes:
- Linters for dependency versions
- Config validation before deploy
- Tests for “what shouldn’t reach prod”
Not because I don’t trust people.
But because good systems don’t rely on everyone always remembering the rules.
My job is to make it physically impossible for people to shoot themselves in the foot. Not through “contact your administrator” restrictions, but through automatic checks that catch mistakes before prod.
Linux gives me rm -rf / - and that’s right, I need that freedom.
But for dev teams, I build systems where :dev in prod simply won’t pass initial validation.
I audit IT infrastructure.
Find not only “what’s broken” but “what will break on the next human error.”
Because prod shouldn’t fall from :dev in package.json.