CI/CD for Infra, Not Just App Dev
CI/CD Series - Issue 4
You ever notice how every CI/CD example online involves:
A microservice
A Docker build
47 unit tests
And someone in a hoodie saying “we deploy 200 times a day.”
Cool.
Now try doing that with a firewall.
“CI/CD” Hits Different in Infrastructure
In app dev land, if something breaks, you roll forward, patch it, redeploy.
In infrastructure land, if something breaks:
The network is down
The VPN is down
DNS is down
Or worse… everything is kind of up but nothing works
There’s no blue/green deployment for a core switch.
There’s just you…
And a change window…
And the sound of your heartbeat in your ears.
The Lie We’ve Been Sold
Most CI/CD content assumes:
Stateless workloads
Rapid iteration
Disposable environments
Infrastructure is none of those things.
Your firewall rules aren’t disposable.
Your BGP config isn’t a feature flag.
Your core switch is not “just another container.”
Yet we keep trying to copy/paste app-dev CI/CD patterns into infrastructure teams and wondering why networking and security people panic.
So What Is CI/CD for Infrastructure?
Let’s translate this into sysadmin language.
CI for Infra = Validation Before Damage
Continuous Integration for infrastructure is not about deployments.
It’s about feedback.
Before anything touches prod, your pipeline should:
Lint your Ansible playbooks
Validate Terraform syntax
Check required variables
Catch obvious config mistakes
Show you the diff
CI for infrastructure means catching broken configs before you reload prod.
If your “CI” step only checks YAML formatting…
That’s not protection.
That’s spell check.
CD for Infra = Ready, Not Reckless
Continuous Delivery does not mean “auto-push-to-prod.”
It means:
The change is validated
The diff is visible
The blast radius is understood
The rollout is controlled
CD in infrastructure is about being ready to deploy safely, not racing to deploy automatically.
If your pipeline auto-applies firewall rules with no approval gate…
That’s not maturity.
That’s optimism.
Pipelines Are Guardrails, Not Speedrun Buttons
Some teams treat pipelines like this:
“The faster we can push changes, the more DevOps we are.”
Infrastructure doesn’t reward speed without control.
A good infra pipeline should:
Block risky diffs
Highlight rule explosions
Catch missing variables
Detect config drift
Force visibility before impact
It should slow down disasters.
Not accelerate them.
If your pipeline is just a dashboard that turns green…
But no one actually reads the output…
It’s decoration.
Why GitOps Makes Auditors Weirdly Happy
Here’s the part no one tells you:
Auditors don’t care about your YAML elegance.
They care about:
Who changed this
When they changed it
Who approved it
And how you can roll it back
When your infrastructure lives in Git:
Every change has history
Every diff is reviewable
Every approval is traceable
Every rollback is possible
GitOps isn’t about buzzwords.
It’s about making auditors slightly less suspicious of you.
Which, frankly, is a win.
The Infrastructure Reality Check
CI/CD for infra is:
Slower than app dev
Higher stakes than app dev
Less flashy
Way more stressful
But done correctly?
It gives you:
Predictability
Traceability
Confidence
And fewer 2AM “why is the core down?” calls
And that’s the kind of automation we actually want.
👀 In the Extended Version
In the paid version, we go deeper and more practical:
A real-world CI pipeline example for Ansible
What Terraform validation should actually check
How to gate risky diffs (not just syntax errors)
Firewall rule testing strategies that don’t cause outages
How to design approval gates that protect prod without slowing engineers to a crawl
The infra CI/CD maturity model (and how to know where you really are)
What you absolutely should not automate
If you’ve ever stared at a “green” pipeline and still felt nervous…
The extended version is for you.
Automation isn’t about moving fast.
It’s about moving safely, repeatedly, and without drama.
And in infrastructure…
Drama travels at line rate.
— JJ – Chief Packet Pusher.