Comments on: Configurable Builds: One configuration file per environment

By: Configurable Builds: One configuration file per machine at Mark Needham

Configurable Builds: One configuration file per machine at Mark Needham — Sat, 13 Sep 2008 02:57:42 +0000

[...] One configuration file per environment [...]

By: Eric Minick

Eric Minick — Tue, 02 Sep 2008 16:55:02 +0000

In general though, I'd see a build per environment as an anti-pattern. Rebuilding between deployments to various testing environments hurts your traceability between those tests and the guarantee that what you deploy in a late testing environment or production was actually tested earlier.

A similar nant deployment script that takes properties per environment and modifies an already built application's configuration files based on those properties seems to be along the same lines, but without the unneeded rebuilding.

At least we hope the rebuilding isn't needed. We don't have configuration being compiled with source code do we?

By: Configurable Builds: One configuration file per user at Mark Needham

Configurable Builds: One configuration file per user at Mark Needham — Tue, 02 Sep 2008 12:59:58 +0000

[...] on from my first post about making builds configurable, the second way of doing this that I have seen is to have one [...]

By: Jim Barritt

Jim Barritt — Tue, 02 Sep 2008 12:51:13 +0000

We have a similar thing except it gets its filename from the name of the machine you are on when on a dev box…

so for example my machine name might be GNM23454 and there would be a properties file called :

environment.GNM23454.properties

In there is a DB connection and everyone has their own login and oracle DB schema.

We have a couple of helper targets on the build which tell you which DB you are connected to.

Its all running under ANT

By: Mark Needham

Mark Needham — Tue, 02 Sep 2008 08:32:29 +0000

As necessary is probably more accurate you're right.

It's always interesting looking at the trade off you have to take between making something configurable and the levels of indirectness you end up creating as a result.

From what I've seen I think at most you should only have one extra configuration file that you need to look in for properties – when you have the properties scattered all over the place it becomes really painful as you say.

So in this case we would only need to look for properties in dev.properties.xml or qa.properties.xml and that would give us everything we need.

By: Jim Arnold

Jim Arnold — Tue, 02 Sep 2008 08:26:20 +0000

"One of the most important things when coding build files is to try and make them as configurable as possible".

As possible? Or as necessary? I dread wading through heavily configurable build files; jumping around to figure out where properties are defined and set. I'm not saying they shouldn't be flexible, but YAGNI applies to scripts too!

By: Ketan Padegaonkar

Ketan Padegaonkar — Tue, 02 Sep 2008 04:45:56 +0000

Here's what we do for the Twist builds, given that we build and deploy on various platforms:

build.developer.properties is an override for it all, which is what most developers on 'non-standard configuration use'

We check in the property files for all hosts into svn. So individual machines can always pick them up from the source tree. Dev machines probably don't have this checked in.

build.properties is just the default values for everything else.