Configuration - Externalizing /Externalization

https://reflectoring.io/externalize-configuration/

The Road to Hell: Internal Configuration

The configuration parameters are inside of the deployment artifact, which is why I call this internal configuration.

So what’s wrong with this approach?

First off, this approach doesn’t scale. Each time we’re changing a configuration parameter we have to re-build and re-deploy an artifact. Each time we have to wait for the build to finish before we can test the change.

Basically, it all boils down to this approach being a violation of the Single Responsibility Principle. This principle says that a unit of code should have as few reasons to change as possible.

If we transfer this principle to our deployment artifact, we see that our deployment artifact simply has too many reasons to change. Any configuration parameter is such a reason. A change in any parameter inevitably leads to a new artifact.

A clear indicator for internal configuration is when the build process takes a parameter that specifies a certain runtime environment.

External Configuration to the Rescue

Within each environment lives a configuration that is valid for this environment only. This configuration is passed into the application at startup.

This approach negates all drawbacks of internal configuration discussed above.

• Fixed File Path Directory having config files
• Config Server
• Cmd line
• Environmental Variables