Sprimera: A Spring Profile Merger

Spring profiles are the core of any micro-service architecture for multi-environment support in an application. They allow the application to configure properties by adding/overriding properties based on the environment. Hence, maintaining and segregating profile-specific configurations becomes very critical for an organization.

What are profiles in Spring Boot?

A profile is a set of configuration settings. SpringBoot allows defining profile-specific property files in the form of application-{profile}.yml. It automatically loads the properties in a application.yml file for all profiles and the ones in profile-specific property files only for the specified profile. The properties in the profile-specific configuration override the ones in the master configuration.

To know more about the spring profiles, refer to this link.

How does the SpringBoot application decide which property to import from which profile/configuration?

A SpringBoot application has a specified structure to fetch the configurations.

Let us consider our spring application name to be my-app. The order in which the spring would load the different configuration would be as follows:

spring.application.name=my-app

Fig 1.1 Spring Configuration merge order

The properties are imported in order from top to bottom. If the properties are also available on lower configurations, the property would get overridden by the lowest configuration i.e. if the same property exists in the my-app-{profile}.yml (1) and application-{profile}.yml (2), then the property in (1) would be taken as final property.

From the above explanation, we can also conclude that the properties present in the lower configuration have higher priority than upper configurations. If a property is imported from my-app-{profile}.yml, it would not be overridden by the upper configurations.
(This approach has been implemented below in the Solution 2)

What is the current approach to reading these configurations provided by SpringBoot?

SpringBoot, out of the box, provides us with the support of SpringBoot Admin to manage and monitor our application. Besides this, it also provides us the feature of analyzing the custom configuration from the Environments tab in the SpringBoot Admin.
Below configuration is an example of configurations that I have used for my application.

# application.yml properties
---
spring:
  profiles:
    active: prod

custom:
  name: ashish
  occupation: developer
# application-prod.yml
---
custom:
  role: learn

  excludeUrl:
    - localhost:9080
    - localhost:9871
# bootstrap.properties
---
spring:
  application:
    name: my-app

Fig 1.2 SpringBoot Admin Environment details

What is the issue with this visualization?

Even though the SpringBoot Admin provides us with detailed knowledge of all the configuration and their properties, the required information to the developer is “which property is used and from where it was imported?”.

Fig 1.3 SpringBoot Admin property-value search for custom property

custom:
  excludeUrl:
  name:
  occupation:
  role:

From Fig 1.3, we can analyze that the custom property has 4 embedded properties i.e. name, occupation, role, excludeUrl. From Fig 1.3, it is not very readable from where the properties are imported.

There are multiple ways to analyze where the properties were imported from.

Solution 1 (Traditional Way)

Since the developer knows the order of configurations in which they are imported into the application by SpringBoot, they can manually find the properties and analyze from where they were imported.

The problem with this approach are as follow:

1. The user may need to load the application in the local system multiple times or hit the /actuator/bus-refresh multiple times to update the spring configuration.
2. It is very time-consuming as it requires manual work.
3. It would affect the efficiency of the developer.

Solution 2 (Sprimera: Spring Profile Merger)

Fig 1.4 Sprimera Tool

The tool is designed to merge multiple configurations and let the developer know:

1. The final configuration that would be used by the application.
2. From where the properties are imported.

How do we use this application?

Step 1: Load the files into the application.
Step 2: Drag the files to specify the order (high to low priority).
Step 3: Can change the merge option from JSON to YAML merge (default JSON)
Step 4: Click on the Aggregate button to merge the configurations and get the final configuration.

Advantages:

1. Can modify the configuration and get the output without loading the application in the local system (no dependency on the Spring Application).
2. Manual work is reduced to 1-click event.
3. Supports upto 7 number of custom-configuration at a time.
4. As a developer, we write in YML/JSON, hence reading it in the same format is comfortable.
5. Verifies whether the file content is in valid format.
6. Double-clicking on the property can give the path of the property. Furthermore, the path can be used to navigate to parent property as well.
7. The user can check if a specific property exists or not in the configuration. If exists, the editor would navigate you to that line.
8. User can aggregate the configurations in JSON as well as YAML format.

Limitations:

1. Only supports up to 7 configuration files (due to colour distinct limitation).
2. Only take YAML files as input.
3. YAML merger has issues with locating the line number in case of [|- , |+ , > ] in string property values. Only supports | in configuration.

FUN FACT :
Sprimera is derived from two words: SpringBoot and Chimera.

Deployment and Github Link

Sprimera Tool Link: https://sprimera.herokuapp.com/
Example File Link: https://drive.google.com/drive/folders/1KxBP1gNlczWKJrnnMkaUGtbspuyjdcER?usp=sharing
Github Link: https://github.com/ashishgopalhattimare/sprimera