ci-cd-audit

CI/CD Audit

Overview

Deployment should be boring. If deploying is scary, your pipeline is broken.

Core principle: Every deploy should be automated, tested, reversible, and auditable.

The Iron Law

NO MANUAL DEPLOYMENT STEPS. NO DEPLOY WITHOUT AUTOMATED TESTS. NO DEPLOY WITHOUT ROLLBACK PLAN. NO SECRETS IN SOURCE CODE.

When to Use

• Setting up or reviewing CI/CD pipelines
• After a failed deployment
• Before first production deploy
• When deployment takes too long or fails too often
• When different environments behave differently
• During any codebase audit

When NOT to Use

• Personal scripts or local dev tooling (not deployment)
• Evaluating which CI platform to choose (this audits existing pipelines)
• Library/package projects with no deployment (use dependency-audit)

Anti-Shortcut Rules

YOU CANNOT:
- Say "pipeline looks fine" — read every stage, every config file, every env var
- Say "tests run in CI" — verify they BLOCK deployment on failure (not just advisory)
- Say "we have staging" — verify staging matches production config structure
- Say "rollback works" — verify the procedure is documented AND tested
- Say "secrets are secure" — grep the repo for hardcoded values
- Skip checking deployment logs — read the last 5 deployments for warnings
- Assume environment parity — check runtime versions, deps, config in each env

Common Rationalizations (Don't Accept These)

Rationalization	Reality
"We deploy manually because it's faster"	Manual deploys are faster until they fail. Then it's a 4-hour incident.
"We don't need staging"	Local ≠ production. Network, DNS, config, secrets, scale differ.
"Tests slow down the pipeline"	Slow tests = testing problem. Fix tests, don't skip them.
"We've never needed to rollback"	You haven't needed to rollback YET. When you do, 5 min vs 5 hours matters.
"We deploy from our laptops"	One compromised laptop = compromised production. Deploy from CI only.
"Friday deploys are fine"	If they require bravery, your pipeline lacks confidence signals.