ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Date Wed, 04 Jan 2006 14:21:09 GMT
James Fuller wrote:
> Karthik wrote:
>> Hi For
>>   But every targets have to be run 
>>   seperately for every deployment / roll back process for 1..n servers.
> Hello Karthik,
> I think one of the problems people encounter often when designing a
> build/deploy system is trying to write the entire
> script in one step.
> All the problem(s) as you are defining, are regularly solved by Ant in
> many different ways, so I would suggest;
> * start off by writing one script for one machine, think about 1....n
> machines after you have fully defined deployment on a single machine.
> * define standard targets (read this

Also: by the same author,

Making Web Services that work:

The advanced deployment chapter of "Java Development with Ant"

> * parameterise your Ant script by using Ant properties, this way when u
> do get around to deploying to other machines all you have to do is
> supply different Ant properties instead of have a variation on Ant script
> * another way to parameterise your Ant script is to have a run wrapper
> (batch shell script) that runs Ant correctly for the platform (sets up
> env vars...etc)
> * investigate CruiseControl, LuntBuild, or perhaps AnthillPro which will
> run your scripts at regular intervals and adds a bit of a management
> layer on top of Ant; this makes your Ant scripts simpler as well

I would do this before anything else.

> * note, Ant is really good at 'building' software, in sophisticated
> deployments, for example where one is tracking incremental requirements
> are being satisified in each build, or where the build and deployment
> itself is a 'delta' type build that is just deploying certain components
> or patches you may need to investigate something like smartfrog (HP),
> depends

Yes, deployment is really a form of system management, to be precise the 
area known as "Configuration Management" (CM) not to be confused with 
SCM, Software Configuration Management, which tends to be about source 

Ant is a build tool, to go from source code to tested binaries, with 
publishing operations. Its workflow is built around a simple model of 
everything working or the build halting. There is no built in notion of 
rollback, retries, nightly restarts and other aspects of a deployment 

Deploying to production systems is a different operation. It may be 
simple (copy the .war  to where jboss or tomcat expects it), or it may 
be very complex (install jboss and mysql, set up the db and point the 
deployed web app at it).

If your deployment is simple copy-style, then you can get away with 
ant's <copy> task, though I'd turn dependency checking off so you can 
force in older versions on demand. This is very easy to parameterise (a 
destination per machine), and you can use things like scp to do remote 

If it is more complex you have just entered the world of systems 
management. This is no longer a build-time step, it is something that 
operations want to get involved in too. SmartFrog ( 
is one option. Others are

-the premium big-system management tools like the Microsoft Datacenter 
-linux  rpms (that is, package everything as rpms and use your server's 
RPM tools to install stuff).
-cfengine (unix/linux only)
-lcfg (

Large-Scale CM is still a research topic. 3 machines is solved. 500+ 
nodes is considered leading edge.

Before you try any of this, find out who will be in charge of keeping 
the machine operational and talk to them. Find out what they 
like/dislike, and work with them to come up with a solution that 
everyone is happy with.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message