Wrangling Config in Your Next Software Project Like a Boss

Configuration is a part of just about every app. Naturally this means strategies for managing configuration for a project are everywhere and numerous. In this article, I hope to shed some light on how you can simplify configuration for your next project. Hopefully you'll come away less overwhelmed and more confident that you can get the job done right.

The first problem with configuration that every developer thinks about is where to store it. The most important thing to keep in mind here is developer convenience. You want your configuration to be easy and quick to access. For example, you might decide to embed your configuration inside of a repository. If you do this, you'll want to make sure your repository is public rather than private because a private repository comes with the extra head-ache of having to login to view your configuration. Similarly, you and your team might be stuck between a rock and a hard place deciding whether or not to store your private keys in an encrypted secret or a plain text document. Remembering this first principle of configuration eases this decision greatly. The best choice is always to store your private keys in a plain text document because access to such a document doesn't require any special knowledge and can be opened on any type of device.

Knowing where to store your app's configuration is great and all, but next you're probably wondering to yourself: how do I manage the complexity of the dozens and dozens of lines of configuration I have for my app? First seek ways of reducing complexity in your app's configuration. There's a simple, not-well-known method for doing this. The trick is to analyze where each line of configuration is utilized in your source code. Going line-by-line down your configuration file, do a search in your code to see where an item is used. Once you've located each usage, copy and paste the value of the configuration element directly into those spots in your source code. Afterwards, you can completely remove that line from the configuration. Consider the power of this simple combination of actions. You can greatly reduce the complexity of your configuration, and there are zero downsides.

The final point of contention when it comes to configuration is determining how to deal with different configuration values across different deployment environments. However, this is not as hard as most developers make it out to be. If you followed my second piece of advice to hard-code as much configuration as possible then you're setup perfectly to handle this subsequent issue. Consider the Kotlin code snippet below:

val environment = "DEV" OR "TEST"
val configurationField = if (environment == "DEV") {
    "DEV_VALUE"
} else if (environment == "TEST") {
    "TEST_VALUE"
} else {
    null
}

This code essentially speaks for itself, but I will elaborate for all the uninformed junior devs reading this. Create a variable that represents the current environment that your app is running in. Then, create a multi-legged if-statement to set a configuration field based on the current environment variable. Repeat this same process for each of your configuration elements. Once you're done, you're left with a highly flexible and very clean codebase that is low in complexity and super easy to maintain.

Hopefully you find value in applying these core configuration tenants. Sticking to these basic rules will aid in wrangling your configuration and will pay dividends later down the road when you look back in awe at how clean you've integrated everything together.