Yaaays part 2 is finally here. In the first part of these blog series we talked about how environment variables are very useful for our apps. Now it is important to know how to manage them along with other configuration related info. There are many ways of doing that but my preferred approach is to split them into dotenv (.env) and config files.
Dotenv what? Yes this secret little file that usually contains all the environment related information. It is something that devops engineers love! For your own sake you should start loving it as well otherwise they will replace everything with yaml files.
Dotenv files are something that should not be stored on Github or any other version control system as they normally contain sensitive information. A common practice is to include a .env.copy file which has all the default environment values. To get started we need to instruct users to make a copy of that file and rename it to .env. It is important that the application’s readme file contains instructions for that to avoid confusion when onboarding new devs. They can then crack on setting up their environment without issues. Why not store the .env file itself on Github? It is because that may introduce complexity when deploying code as these files are going to be replaced by deployment scripts.
As mentioned already, dotenv files are supposed to contain environment / ops related information. In most cases that also means information that should be kept secret. So using dotenv files also promotes better security as following this practice prevents us from storing sensitive information on Github. That way each different environment is going to have a separate dotenv file which will only be known to the script that is responsible for deployments. I really hope that these scripts are not stored in a public repo 😆
In case I have not made it very clear so far let me say that again. Devops engineers LOVE dotenv files. If you ever reach a point of uncertainty and wonder if a key value pair should or not be a part of a dotenv file, then I have a trick that will give you an instant answer to that question. Just ask yourself the following. If someone from devops sees that variable will he/she respond with “what am I supposed to do with that???” If the answer is yes then that key value pair does not belong there, it belongs to the config files. Now time to talk about config files. (smooth transition)
Config files are designed to have application related information. I bet that if you open ANY React or Node.js project, there will be at least a couple of config files on the root directory. Stuff like jest.config.js, .babelrc, tsconfig.json or even package.json just to name a few common ones. All of them store information that is directly related to our application.
Usually such information is visible and open to the public. It does not really matter to hide config files as they are static, meaning they do not change that often. It is also not very likely for them to change in different environments. If a config value has to change due to deploying to another environment, that means that it belongs to be inside the dotenv file.
It is common to see engineers sharing their config files on Twitter isn’t it? It has become a “who’s the coolest kid on the block” kind of thing to have to do so. This is because knowing that kind of information can not really cause any harm. However, sharing the credentials to your Production DB Master replication table can cause chaos so please don’t. For really sensitive information it is recommended to use secrets.