It's hard to see a developer that cares and nourish a good relationship with all the properties files in the system. When you have only a few properties defined it's very easy to handle and understand what's going on. However, when you start to have a big file with a lot of lines and a few modifications per release it's going to be a nightmare to understand what is going to production or not.
Properties left in the file
The first thing that I notice is that when there is a lot of modifications in the project a huge amount of properties will be added, and then after a few releases they will be not in use anymore, this is the case normally of feature flags, when the team enables the feature flag they forgot that they need to remove the property causing noise when it's going to production.
My suggestion would be simple to remove when the team is not using it anymore.
Properties not structured
When the file is big, and you have several files for each environment, or even worst one file for all the environments as the .yaml file enables us to have it, and the properties are out of order. When you need to verify if the properties are the same or if they are there, it's going to be really hard to find, and humans make mistakes.
The best way to handle that situation is to have a good structure that binds the properties in the following lines something like if it's HTTP calls, everything under an HTTP hierarchy.
Another solution for this is to have a code that checks, this will help, but will allow the developers to create a file that is a mess.
One file for all environments
if you have 30 lines of properties and you have 4 environments(DEV,QA,PRE-PROD,PROD), in one file you have 120 lines of properties. When you need to see if the property X is going to production and that property was only added in QA environment you will need to scroll up and down a few times get lost in the file(hahaha, happen to me several times) to see if the property is set into production correctly.
A simple solution would be to have different files for each environment and use git diff to understand what is different between the files. And if the properties are in the same order the diff will be easy to solve it.
Don't use files cross environments but use common files for each environment
When you have a file that it's shared between all the environments there is always the possibility that someone merges something that is for dev and ends up going to production, and this is something that we don't want to even have the small possibility. However, a good thing to have it is a file that in the same environment is shared between all the apps, could be a centralized feature toggle, or another type of property that is commonly shared between all the apps. Having a few files shared between the apps is good to understand what's that the system is using without the need to look in each file from each app.
Protect Production Properties
We don't want, at least mistakes that can be easily avoided, to go to production, like properties errors. By saying that my thoughts are that we need to have a way that the developer needs to explicitly says that he wants that modification to goes to production minimizing that mistake by not paying attention, the famous git push -f.
A suggestion to that is to have a branch to hold the production properties or a tag, that the developer needs to point to that to send the properties to production.
Do not create breaking changes in the properties
Try always to not have breaking changes, something like changing the property name or value directly. Try to add a new property that will hold this new version of it, deploy it, see everything work, then remove the old one, and change that new property to the current. By doing this if you have an automated deploy you will be able to always deploy and rollback smoothly.
Top comments (0)