2
votes

I'm wondering what is the best way to support multiple build versions using ant. In my current project I have 3 environments (development, test, production). There are 2 production servers with different configs (different databases, active directories, webservice urls, etc).There are at least 2 test versions running at a time. There are additional configuration options that are added just to test behavior with something enabled/disabled.

How to handle it all using ant?

Currently we have some directory with set of files for each configuration (persistence.xml, datasource, web.xml, jboss-specific files, several application property files...) which are copied into proper directories during the build (it's becoming A LOT, and change visible in all configurations requires us to change file for all configurations).
There are tasks like build-moduleA-dev, build-moduleB-dev, build-moduleA-test...

In general the build process looks as follows:

  1. load build properties
  2. compile server classes into build dir
  3. compile web classes into build dir
  4. build interface (gwt)
  5. copy static resources and proper configuration files into build dir
  6. create ears/wars/jars

So, I am wondering:

  • How to make it simpler?
  • Is it better to keep seperate files or use something like replace task?
  • How you do it?
1

1 Answers

3
votes

It's not clear from what you wrote if you are doing this already, but you should be producing the same build artefacts for each environment, which can then be promoted through the different environments as part of your build pipeline.

In terms of your per environment configuration, you can look at treating them as build artefacts as well, with the difference being that there is a different artefact for each environment. Another approach is to store the configuration in a DB or LDAP, that your application loads when it starts up. However there is usually some environment configuration that can't be stored in an DB or LDAP, at very least the DB or LDAP to get the environment configuration from.

Your deploy process for a particular environment then depends on the build artefacts and the configuration artefacts for that environment. I've used Apache Ivy with Ant to manage these sorts of dependencies (as well as normal dependencies) and I can highly recommend it.

Also for your deploy process you should be using something like Puppet or CfEngine. They allow you to perform idempotent deployments to your environments, so that rather than saying "given the state I think the environment is in, perform these actions to take it to the state I want", it allows you to say "regardless of the state the environment is in, figure out the actions that need to be executed and execute them, to put in the state I want".

I know this goes beyond your question about managing configuration, but it's only with the whole deployment pipeline picture that you can move towards a better way to manage your per environment configuration.

For more details on deployment pipelines, I highly recommend the book Continuous Delivery. I'm sure you'll find Chapter 2: Configuration Management highly relevant.