Externalizing configurations.

Motivation why to externalize configuration:

• Externalize config data from the applications across all environments. 
• Store crucial information such as password for DB in a centralized place. 
• Share data between different services. 
• See who changed which property and when and why. 
• Build once deploy anywhere. 

What is Cloud Config server: 

Its a way by which we can externalize the property values by moving out of the project. Primarily kept for properties that you normally override or keep secret values out of the project src. 

What should you do to use Spring cloud config

1. Application configuration: 
• Manage app configuration in a git hub or a local file system. 
2. Config server
• Point the location of GIT or local file system where the app config is located (i.e., GIT URI)
• @EnableConfigServer
3. Config client
• Use it normally as how you would read from the properties file 
• @Value or 

Features

• Many storage options including Git, Subversion. 
• Pull model
• Traceability
• @RefreshScope for allowing properties to refresh. Calls the constructor of the beans and reinitializes it. 
• @ConfigurationProperties alternate for @RefreshScope which does reinitialize the Bean that is annotated with @ConfigurationProperties. 
• Encrypt and decrypt property values. 

Usecases for Cloud config: 

• Change log level in the properties. 
• Environment config - containing passwords. 
• Toggle a feature on or off. 
• Using @RefreshScope
• @ConfigurationProperties. 

Order in which the Cloud config looks into the properties files. 

• Config server. 
• Command line parameters
• System properties.
• Classpath: application.yml file
• Classpath: bootstrap.yml

Things that you can try: 

• Simple example to demonstrate properties in Git and reading from config server and client 
• Using maven profiles specific properties in Config server in Github. 
• Managing log levels in the Config server
• Using @RefreshScope and @CofigurationProperties. 

Best practices: 

• Config server communication with the Git hub, pull every time when client requests for properties file. Use a Jenkins job which will push the properties to a Config server properties (clone). 
• Single repository for all teams, subdirectories for different environments. 
• Source code maintenance, having branch per release vs always using the master. 
• Managing encrypted values for secure data, using JWT with Config server.
• Use Spring cloud bus to refresh all the services which listens to the rabbitmq.

Note: 

• Store only things that need to be externalized, I.e., Resource bundles for internationalization should be at the project level.