Stop Using Spring Profiles Per Environment

Lately, I’ve come across a lot of discussions and articles about Spring’s feature called Profiles that are promoting them as a way to separate environment-specific configurations, which I consider a bad practice.

Common Examples

The typical way profiles are presented is by having multiple configuration files within the resources folder that will be bundled within the application artifact with application-prod.yml like:

some-resource.address: prod-address
some-resource.username: prod-user
some-resource.password: prod-password

Issues

I hope one can immediately see some of the issues:

• Applications’ production credentials are committed and available for everyone with access to the repository, which is a very serious security issue.
• Changing configuration value on a given environment would require recompiling and the creation of a new artifact.
• The introduction of a new environment would require recompiling and the creation of a new artifact.

Recompilation and release of a new application version without really changing any application logic feels stupid.

Solution

How can this issue be solved?

Well, config values have to be put outside of the application’s artifact and VCS repository as recommended by Twelve-Factor App.

There are at least two ways I have experience:

1. Having a config file beside application.jar (or specifying spring.config.additional-location) on a given environment overrides only specific keys.
2. Use environment variables.

In the latter case, config keys are bound with environment variables e.g. some-resource.username <=>SOMERESOURCE_USERNAME.

If a custom key name is needed, an “alias” can be made as:

some-resource.username: ${OTHER_ENV_KEY}

In either case, what’s the need for config files per environment?

All that is needed is a single application.yml file with both internal and external properties required by the application.

These properties can have either empty or default/local values.

some-resource.address:
some-resource.username: username
some-resource.password: ${OTHER_ENV_KEY:123456}

When to Use Profiles

So far, I have never had a need for profiles per environment. 

However, there is one “special” profile that I would not consider an environment configuration file, and that is test the profile located in src/test/resources/. This profile and its corresponding configuration file allow overriding only present keys.

Having application.yml file in the given folder would require providing all config properties defined in the main file (if that’s not an issue, go for it).

To activate this profile, use @ActiveProfiles annotation on test classes.

The only other usage of profiles I can think of is some optional feature config grouping.

One advantage of the profile’s mechanism in configuration files is its ability to merge/override config properties (for details, check Piotr’s TechBlog and his Github playground project). 

If we have some optional feature, which requires a separate set of config attributes that we want to be added only if this feature is active, we could have application-{feature-name}.yml, which can be activated in the main config file via spring.profiles.active/include properties.

For simple feature flagging, I would use @ConditionalOnProperty annotation.

Conclusion

To conclude, don’t store environment-specific configuration inside the application and instead use externalized configuration managed/injected on a given environment.

Note: Please feel free to share your opinion and experience on the usage of profiles for environment-specific configuration files or in general. I might be missing something or made a mistake, and I would like to broaden my knowledge.