Configuration Management is an important aspect of software engineering. This article will highlight the why and what of the problem and reason about the different solutions that exist.
The approach to managing configuration changes as the app scales — both in terms of traffic and developer team size. To illustrate the journey, lets start with a simple app.
This is a simple server app that connects to MongoDB and returns the list of users. The code is just pseudo code and is not meant to adhere to any language.
Hardcode configuration in app: a BIG NO!
Hardcoding the MongoDB uri into the app will it really hard to run the application in any other environment — like fellow teammates’ laptops, or for production. We should follows the 12 factor app methodology here to separate config from code.
“ SEPARATE CONFIGURATION FROM CODE “
Now the question is what comprises an app’s config? Quoting from https://12factor.net/config
An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:
1. Resource handles to the database, Memcached, and other backing services
2. Credentials to external services such as Amazon S3 or Twitter
3. Per-deploy values such as the canonical hostname for the deploy
The easiest and most common way to separate configuration from code is to put the variables in a .env file.