Add a new environment property to Plek

[boffbowsh]

Provides an easy way to identify the environment we’re currently
running under.

For backward compatibility purposes, what used to be “preview” (i.e.
preview.alphagov.co.uk) is now referred to as “integration” using
this API. This provides a stable value for any applications using this
new API without needing to be concerned about distinctions between
preview and the new integration environment.

/cc @alexmuller

Also included, making tests pass in Jenkins. Seems it's been a while since Plek development occurred.

[mattbostock]

I don't have strong opinions on this. We do however have an environment variable, ERRBIT_ENVIRONMENT_NAME, which is set in each environment appropriately. I wonder if we should create an environment variable for each piece of functionality that relies on the environment name, rather than have a generic variable, which can become difficult to manage.

[boffbowsh]

I think managing and maintaining multiple vars per app might be worse, personally. Open to opinions from others.

[mattbostock]

The reason being that if we have implicit dependencies on one environment variable, it can create additional complexity if the use case changes later. We've actively tried to reduce the use of such variables in our Puppet code base, for example.

[mattbostock]

This better explains what I'm referring to:

http://12factor.net/config

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

[boffbowsh]

Closing in favour of a behaviour-specific variable.