The Back Story
Lokesh, one of our backend developers, had a need to toggle a feature in production. And he thought of using an environment variable to do the job. When he was asked “WHY”, he went deeper into it and delivered an amazing session on the use of environment variables and the various other alternatives that we end up ignoring or being unaware of.
Btw, he changed his decision of using an environment variable for the job and made the choice of commenting code and re-deploying. Here’s the story of what he discovered and what made him make this choice.
What are environment variables?
Environment variables set or affect the execution context of our applications. In larger system context, they are referred to as the environment variables that are set at the OS, virtual machine or container level. All applications running within the OS, vm or container will have access to these variables, not just our applications. eg: export PATH="/usr/bin"
The big mistake
We as application developers mistakenly use the word 'Environment variables' for what are actually 'Application config variables'.
This leaves them with only one choice, which is a very good choice - to use environment variables.
But we shouldn’t be using them and, even if we do, we should think of them as application config variables, rather than environment variables.
So, what are application config variables?
Application config sets the execution context of our applications based on the deployment environment. It is likely to vary quite a bit based on deployment environments (eg: dev, test, prod, staging).
"Config changes, but code doesn’t. Code can be made open source, config cannot."
Multiple options, different use cases
Config that’s really code
Stop using the same hammer for every use case. A good developer knows the various types, and knows which one is the best for the job at hand.