app.properties | the wrong way

The wrong way is the common way! Before doing app.properties right, let’s touch on what app.properties is used for and the common way (the wrong way) of working with it.

App.properties | What is it For?

You’ll find the file either in the user’s home directory or off it inside a dot prefixed folder. You’ll find it in Windows (for dev environments) – in the jenkins home for continuous integration and in tomcat‘s home for web application environments.

The 3 Reasons for App.properties

app.properties exists as a solution to three problems namely

  1. to look up specific services for each environment
  2. to keep secret keys out of the software (and the scm)
  3. code changes are not needed just for config changes

these services for this environment – The dev environments use this database and that email server, so app.properties specifies the database host, port, user and password. These differ for test, canary, and production environments so the app.properties tells the software which specific services to use.

secrets are kept out of version control – Even though this is a good thing – keeping the whole application.properties file out of version control is a bad thing. Your jenkins tests pass but the code fails in production because the wrong version of app.properties exists there.

config changes can be effected with a bounce – If the config values were in the code a release would be required to change them. With app.properties, a quick change with vi, followed by an app server bounce (restart) is enough to effect the change.

4 Problems | Working with App.properties

Many common problems come with the common way of working with app.properties. Let’s cover the 4 most prevalent and ubiquitous ones.

  1. failures are undetectable by unit/integration tests
  2. long lived passwords, credentials and sensitive data
  3. snowflake (manual) evolution of each app.properties
  4. you cannot practise the “externalize everything mantra”

1. Repeated Application Failure

Failures occur repeatedly as a consequence of no version control oversight of these files. The failures are due to keys missing and even keys existing that alter the behaviour of the software.

2. Reduced Security (Long Lived Passwords)

Password changes and rotation are a no-no. It is just too much hassle to change them across the board. There is no oversight as you don’t know what will fail where when changing app.properties.

3. Snowflake Evolution Everywhere

Snowflake evolution. The app.properties evolves in snowflake manner because these files are manually changed here there and everywhere. We can’t be certain of the state these very important files are in. They are never tagged, branched, rolled back so their existence, state and contents in anyone’s guess.

4. The Externalize Everything Mantra

I subscribe to the externalize everything mantra Applications built this way can adopt features at an incredible rate.

You must widen your definition of “configuration” to achieve higly changeable software.

I call web page templates configuration so I externalize them instead of embedding them inside the software. This way design teams can evolve the application “in-flight” so to speak without new software builds.

There is one catch however to the externalize everything mantra. You need to locate a lot of resources and for that you need a better way to work with app.properties.

Thankfully – there is one.

A Better Way of Working With app.properties

At first glance, the better way doesn’t seem to add up.

  1. app.properties is version controlled
  2. but without containing any passwords and credentials
  3. the scm app.properties gives different config for different environments
  4. failure is prevented because you’ll know its exact state and contents in each environment
  5. and you can rotate passwords on every release

Let’s go to part II to flesh out a better way of working with app.properties.

Leave a Reply

Your email address will not be published. Required fields are marked *