Environment configuration — why, what and how?

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.

A simple server that connects to MongoDB

Hardcode configuration in app: a BIG NO!

Don’t hardcode variables inside the app

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.

.env file for configuration and code separate in server.js

Once we do this, we need to load the variables in code from the .env file. There are several packages to do like dotenv and dotenv-expand. The .env file is not pushed to Git in this case…