Multi statging or environment configuration in java projects

Multi statging/environment configuration in java projects (using spring)

In a typical software develoment project there exist a set of environments in the development life cycle. Typically the developer will write his code on his local system and test it. On a second stage on a development environment the result of the whole team will be intergrated and testes. On a QA-Environment (Quality Assurance or also known as User Acceptance Test (UAT)) the customer will test the software and approve. Finally on the production environment the software will be used by all intended user. In some teams/companies there might exist lot of more stages and environments to fullfil their requirements on the software development process.

But it is common that among the general configuration items every single environment needs its very special configuration items. (i.e. database connection, legacy host address, etc.).

This article will discuss a method as a best practice to be considered in modern software projects. The method at all is not bound to any technology or framework. But we will show a customization for java based webapplication projects using spring framework.

Inbound / Outbound environment configuration

The worst case and error prone case is that for every environment a seperate package is built with manual changed configurations. In this case it might be that by mistake the development system will access the production database or the the production database will read from the qa database.

One possible easy solution would be to define a single location for the environment dependent configuration outside of the project (named herebey a oubound environment configuration) and always load the configuration in the code from this place:

i.E.: /etc/conf/appl1/jdbc.properties

Although this is a valid solution, there is a big drawback that makes it not the best solution:

The development team needs to take care that in case of changes all environment dependent configurations on all platforms are changed. But they do not have maintain this files by themselves. So configuration errors are likely to happen. And it might also be that the same server/filesystem is used for more than one stage / environment.

The author likes more the inbound configuration method, where all configuration items are maintained as part of the project and populated to all systems. As in some cases it might be the case that the development team is not allowed to maintain the production configuration, a mix of inbound and outbound environment configuration is useful.

Environment Definition

Every environment where the software will be run, needs to define clearly it's stage or environment name.

This can be done by setting environment variables or other kind of configuration. As the value it should be used the environment name as defined by the configuration directories in the next chapter. (i.e. setting java properties: -Dapp.env=dev)

Embedding the configuration files

Within software projects it is common sense to have a conf directory containing the configuration files.

A further step is to define some further directories within the conf directory:

• general
• local
• dev
• qa
• prod
• ...

The conf/general directory will contain all non-environment dependent configuration items. Alternatively this items will reside in the conf directory.

All other directories will contain the environment depending configuration files. In all env directories should be the same file names used and no other files.

For example:

local

• jdbc.properties
• sap-system.properties

dev

• jdbc.properties
• sap-system.properties

qa

• jdbc.properties
• sap-system.properties

....

Using the correct configuration

Depending on the given environment definition (see above) the configuration files should be taken from the defined directories conf/${app.env} (i.e. conf/dev)

Utilising in java spring based web-apllication projects

...