📖 Business
Configuration Management
Configuration management is the discipline of keeping everything that can change between environments under version control: application code, database schemas, build scripts, test scripts, environment configurations, infrastructure definitions, and deployment scripts. Humble and Farley's rule is absolute: "If it's not in version control, it doesn't exist." This is not just about source code — it is about the entire system that produces running software. Configuration management is the foundation that every other continuous delivery practice builds on. Without it, nothing else works reliably.
2
Minutes
2
Concepts
+45
XP
1
How It Works
What belongs in version control:
- Application source code (obviously)
- Database migration scripts and schema definitions
- Build scripts and CI/CD pipeline definitions
- Test scripts, test data generators, and test fixtures
- Environment-specific configuration (as templates or parameterized files)
- Infrastructure definitions (Terraform, Ansible, Dockerfiles)
- Deployment scripts and runbooks
- Monitoring and alerting configuration
Core rules:
- Reproduce any environment from version control alone — no tribal knowledge, no "ask Dave, he set up the server"
- One-command environment setup — a new developer should go from zero to running in a single command
- No snowflake servers — every server is built from scripts, never manually configured
- Configuration varies by environment; code does not — the same binary runs in dev, staging, and production. Only configuration changes (database URLs, API keys, feature flags)
- Store environment-specific config separately — environment variables, config files, or secret managers. Never branch code for different environments
The anti-patterns:
- Manually configured servers that nobody can reproduce
- "It works in dev but not in staging" because environments diverge
- Configuration buried in wiki pages or someone's head
- Different code branches for different environments