We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
A production server had a specific Nginx configuration that handled a complex routing rule. The config had been hand-edited on the server over two years by three different engineers. When the server needed to be replaced, nobody could reproduce the configuration. The original admin had left the company. There was no documentation. Rebuilding the config from scratch took a week of trial and error, reverse-engineering access logs and comparing with other servers.
Configuration as code stores all configuration in version-controlled files. Every setting lives in a Git repository: application config, server config, pipelines, monitoring rules, alert thresholds, firewall rules. Changes are tracked, reviewed, and auditable. Rebuilding any environment means checking out the repo and applying the config.
Etsy famously stores their Nagios monitoring config in Git. Every alert rule change goes through a pull request. When an alert fires at 3 AM, the on-call engineer can git blame the alert to find who added it, when, and why.
| Config Type | Format | Tools | Example |
|---|---|---|---|
| Application config | YAML, JSON, TOML | dotenv, node-config, Viper | Database URLs, feature flags, timeouts |
| pipelines | YAML | GitHub Actions, GitLab CI, CircleCI | Build steps, test commands, deploy triggers |
| Infrastructure | HCL, YAML, TypeScript | , Pulumi, CDK | VPCs, clusters, IAM roles, records |
| Monitoring/alerts | YAML, JSON | rules, Grafana dashboards | Alert thresholds, dashboard panels |
| Security policies | Rego, YAML | OPA, Kyverno, Falco | "No containers run as root" |
| Database migrations | , TypeScript | Drizzle, Prisma, Flyway, Liquibase | ALTER TABLE scripts, seed data |
| rules | YAML, HCL | Nginx conf, HAProxy, Envoy xDS | Routing rules, rate limits, TLS config |
What does NOT belong in code:
The config hierarchy pattern: Most systems layer config from general to specific:
Each layer overrides the previous one. This means 90% of config is shared, and only the 10% that differs per environment needs separate files.
It is easy and good
“It is really nice and good Please join the course”