How can I manage complicated configuration files?
Having a single, monolithic configuration file for AMPS is great for simple environments, but as an instance grows to include multiple teams or applications it's often desirable to partition the config into individual components with different maintainers.
For example, let's say you have two teams, 'a' and 'b', that want to maintain their own SOW topics. You could have a single configuration file, but one team could easily alter the other's topic configuration in undesirable ways (accidents happen!) Ideally, you'd have a team-a-topics.xml and a team-b-topics.xml that could be maintained by their respective teams and included into the larger configuration file.
You can then control which file is used based on environment or command-line variable to AMPS.
In the configuration file, you would specify an inclusion block like the following:
When starting AMPS, you can either set the environment as follows:
or pass the value explicitly on the command line:
When AMPS starts, it replaces ${TEAM} with the value provided, and loads the correct file.
This mechanism can also be used in cases where a given environment doesn't need the functionality that would be otherwise included. In that case, you create an empty file with a descriptive name (in this case, something like team-none.xml would be appropriate), and then pass that value when you start AMPS.
AMPS interprets an empty file as a valid (but empty) inclusion.
Last updated