CI/CD - Continuous Integration
The Least Understood Part
Everyone loves to talk about “CI/CD.”
Very few people can explain CI without immediately pointing at a tool and saying,
“It’s basically Jenkins.”
No.
That’s like saying seatbelts are a car model.
Let’s fix that.
What Continuous Integration Actually Is
Continuous Integration is about feedback, not deployments.
CI answers one simple question:
“If I merged this change right now… would something obviously break?”
That’s it.
That’s the whole job.
CI is the boring but critical step where automation taps you on the shoulder and says:
“Hey, this YAML is invalid.”
“That variable doesn’t exist.”
“This config will absolutely brick prod.”
“Are you sure you meant to do that?”
If CI does its job well, nothing exciting happens.
Which is exactly why people ignore it.
CI Is Not About Shipping Code
Let’s be clear:
❌ CI is not deploying anything
❌ CI is not restarting services
❌ CI is not touching prod
CI is just running checks early so humans don’t have to learn lessons late.
The goal is fast, cheap failure.
Because fixing a typo in a pull request is:
free
quiet
doesn’t involve incident bridges
Fixing it after a reload?
expensive
loud
now you’re explaining it to leadership
What CI Should Be Doing
A sane CI pipeline checks things like:
Syntax validation
Linting
Unit tests
Schema checks
Config sanity validation
For infrastructure folks, this looks like:
Does the playbook parse?
Does the Terraform plan explode?
Does the firewall rule reference an object that doesn’t exist?
Did someone just remove the default route because “it looked unused”?
CI doesn’t need to be smart.
It just needs to be early.
Why Most Orgs Skip CI and Go Straight to Chaos
Because CI is unsexy.
It doesn’t:
ship features
make dashboards green in exciting ways
impress executives
So what happens?
CI becomes optional
tests are skipped “just this once”
pipelines turn into deploy buttons
And now your “CI/CD pipeline” is just:
manual testing + vibes
Which works great until it doesn’t.
CI for Infrastructure (This Is the Important Part)
If you manage servers, networks, or security:
CI is your last line of defense before muscle memory takes over.
CI for infrastructure means:
catching broken configs before reloads
validating changes before they touch devices
stopping “just one quick fix” from becoming an outage
Or, put another way:
CI is how you avoid finding syntax errors via monitoring alerts.
The Dirty Secret of CI
If your CI pipeline fails all the time, people stop trusting it.
If it never fails, it’s probably doing nothing.
Good CI fails just often enough to be annoying
and early enough to be useful.
That’s the balance.
Want the Practical Version? (Paid Subscribers 👀)
The free version explains why CI matters.
The paid version gets into the stuff you actually want to steal:
What real CI checks look like for Ansible, Terraform, and network configs
Examples of cheap, fast CI validations that catch breakage without slowing teams down
How to design CI so it fails early without becoming background noise
Common “looks fine in CI” traps that still blow up prod — and how to avoid them
Basically:
Less philosophy. More guardrails. Fewer outages.
If you’re tired of finding broken configs after reloads, the paid version is where the real value lives.
👉 Upgrade to get the full breakdown.
Coming Up Next
In Issue 3, we’re tackling the argument that never dies:
Continuous Delivery vs Continuous Deployment
Yes, they’re different.
No, auto-deploying to prod is not required.
And yes, this is where networking and security teams start sweating.
— JJ – Chief Packet Pusher