Best Practice for supporting multiple login configs across Environments

Question

This question has more to do with the structure and access of different configurations across a number of levels of development. What I mean by 'levels of development' is environments where the different versions of the code and product live. This can be things like a 'Development' branch, 'Quality' branch, or any of the different 'Production' or 'Release' areas.

We have a number of services that we're creating around a Java VM. Outside of Java, we're specifying a config file that the JAR parses for things like SQL server location, username, and password. We'll need this config file to be different for each environment we have as it goes up through promoting/merging the code through the development process, going from Development to Staging to Quality, etc. since each instance of SQL server will have its own IP address, name, and login information. The structure of each config file may even be different from one another - though it would still be parseable by the JAR.

Since all of this needs to happen, we are left thinking about what the best solution might be. We can't keep the config file in the source control repository (using Git right now) with the rest of the code, because it needs to be different from server to server. Plus, any configuration change that needs to happen should not be a full push/pull and rebuild from that server.

What are some 'best practice' ways of doing this? One idea we looked at was having a separate source control location just for the config files, but that's still undesirable to us.

Answer 1

There are two ways I can think of initially. Both have been used quite successfully in a production environment.

Define by Host

This is basically using a single config file that holds all your configuration settings. Each environment is defined under a different header.

Assuming your are deploying onto different machines for your different environments - you determine which group of settings to use by querying the host machines identity before reading in the settings. This query can be reading the machines IP, hostname or testing for the existence of a file somewhere - there are many ways.

You can even keep multiple files if you wish but I would say if the settings list is small you might find it easier to keep them all in a single file.

Pros: Adapts to the environment straight away. No need to change any versioned code to get things to 'work' correctly. Adaptable to a proxied test environment when using http host headers.

Define by default setting

This is similar to the explanation of defining a config by host. But you check a variable - usually defined within the config file - that indicates which settings are to be used by default.

So at the top of your config file you might have something like;

use_settings: production

Pros: No reliance on environment itself - nothing is expected to be a certain way. IP's, URL's can always change. Environment can be confirmed by viewing the configuration file.

Answer 2

I like the following approach: https://dzone.com/articles/using-spring-profiles-and-java. The basic premise behind is that you set at runtime for each jvm