In our Springboot project, there is usually an application.yml or application.properties file, which is the core configuration file of the entire Springboot project. Usually, the file contains the configuration of important information such as port, program name, and data source.
However, in the actual development process, we need to configure multiple sets of different configurations due to the involvement of multiple environments.
Take the database as an example, it is divided into test environment configuration and generation environment configuration, and their link information is definitely different.
So, in actual work, how do we ensure that the corresponding configuration information is read in the corresponding environment?
[Method 1] A configuration file contains the configuration of multiple environments
In this method, we write the configuration corresponding to multiple environments in the same configuration file. If it is a test environment, then we shield the configuration of other environments and keep only the configuration of the test environment, and the same is true for other environment configurations. .
So what's wrong with this approach?
If the configuration is small, it may be able to cope, but when there are too many configuration files in a project, it becomes more cumbersome to switch between environments, and a large piece of configuration needs to be shielded. And the whole configuration file looks very bloated and not elegant.
So, how do we gracefully configure multiple environments? Let's take a look below:
[Method 2] A separate configuration file for each environment (recommended)
Below, I use practical examples to illustrate how to configure multi-environment configuration files.
In order to distinguish the data, we remove other configuration data and add a line of custom configuration data msg to the configuration file.
And write a test method to get the configuration data.
Start the project, access the request, and you can see that the configuration information has indeed been successfully obtained.
Now, we start to configure multiple environments. Suppose we need to configure a development environment (dev) first, then we can copy the original configuration file and name it application-dev.yml (in order to test the configuration data source, we Add the msg configuration data to the dev logo) 
At the same time, we delete all the original configuration file data and add the following data (dev in the configuration refers to the current environment)
spring:
profiles:
active: dev
We start the project again, access the interface, and we can see that the configuration data of the dev environment has been successfully obtained.
In the same way, we copy a test environment (test) configuration file
. Now we switch the configuration file, only need to modify the active parameter of the main configuration file, so that when the program starts, it will load application-test.yml accordingly document.
Restart the project, access the interface, and you can see that the configuration is the configuration file from the test environment.
In the same way, even if you configure 100 environments, it will be very clear. When the program is started or packaged, you only need to modify the parameters of the environment corresponding to the main configuration file.