Profile specific properties vs Environment variables

Using Spring-boot we can store config parameters for different environments in Profile specific properties file, however that makes config part of code which is what 12-factor principles doesn't recommend .

Rather, 12 -factor recommends storing config(here, config specifically means parameters whose value varies across different environments) in environment.

What are pros/cons of storing config in environment Vs profile-specific properties files ?

Configuration in code

Pros:

1. Single point of truth as all properties are in one location which is easily accessed by everyone in your team. It's easier to compare different environments when all configurations are in one place.
2. The version control system tracks all changes to environment properties. You can describe the reason for change in a commit message.
3. You can validate the correctness of properties during the build process with automated tests and avoid starting your application with an invalid configuration.

Cons:

1. Changing the configuration (even for a single environment) requires rebuild of the whole application.
2. The version control system may be used to store sensitive authentication information, e.g. database passwords. Keeping such values even if encrypted form might be risky.
3. If your organization limits access to production environment for regular developers and has a special operation team dedicated to this role, the development team probably won't have all required configuration details to put them in the code repository.

Configuration in environment

Pros:

1. Changing configuration doesn't require additional application rebuild.
2. Sensitive information aren't stored in the version control system.
3. Runtime configuration update can be implemented.

Cons:

1. Configuration must be verified when the application is started. Especially important if deployments are not automated and executed by someone outside of the development team.
2. The history of configuration changes may not be as clear as using the version control system. The connection between code and configuration changes is lost.
3. Reproduction of a bug might be impossible without knowing the exact configuration of the application when the problem occurred. Tracking external configuration changes is a more complex task.

Nothing is black and white, you can always use a compromise solution which mixes both approaches. One part of your configuration might be suitable to keep it with the source code, while another may be kept outside. As usual in programming it depends on your needs.