Properties versioning with Spring Cloud Config

Question

I am probably missing something here, but what is a good solution for properties versioning?

For example, in a blue-green deployment scenario with property value changes (old app version consumes the old value, new version requires the new value), how do you ensure both versions of your app can successfully co-exist (considering potential restarts and rollbacks)?

One option would be to create new property names for the properties that need new values applied. This, of course, is not a good option as we need to track all the usages of that property in the code base and update its reference accordingly. It is also not nice from a conceptual perspective.

Another option is to have a branch for each release. While this could work very well for this scenario, I envisage a branch/tag hell as we scale to the config repo to multiple apps and their respective branches evolve into different directions.

A solution to the branch hell would be to have a separated config repo for each app. But, I believe this in some sense defeats the purpose of the config server as it adds overhead.

Any other approaches?

Answer 1

Spring Cloud Config's Environment resources are parametrized by three variables:

1. {application} maps to spring.application.name on the client side
2. {profile} maps to spring.active.profiles on the client
3. {label} which is a server side feature labelling a versioned set of config files.

Since in case of Blue-Green deployments, you're using the same application in the same profile, the best option is to use Versioned config files by using git Tags.

The basic idea is to create tags for different versions of config files and tell your application to use configurations related to an specific tag using spring.cloud.config.label in your bootstrap.properties.

For example, you can tag two different commits with v1.0 and v2.0:

And use spring.cloud.config.label=v1.0 for old instance and spring.cloud.config.label=v2.0 for new instance.

as we scale to the config repo to multiple apps and their respective branches evolve into different directions.

In order to avoid this problem, I suggest to only save common and cross application properties in application-{profile}.properties config files. The better approach is that to each application has its own config file, e.g. recommender.properties for recommender service and search.properties for search service. Then you can use profile specific and versioned properties for each of them by defining the appropriate spring.application.name. This way you can achieve to some level of Single Responsibility Principle in your configuration files.