Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43C3C387.2000606@apache.org>
Date: Tue, 10 Jan 2006 14:24:07 +0000
From: Steve Loughran <stevel@apache.org>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: OT (slightly) Rake + SwitchTower
References: <43C3664C.40308@it.fts-vn.com>
In-Reply-To: <43C3664C.40308@it.fts-vn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kev Jackson wrote:
> I'm currently exploring SwitchTower[1] to see how far I'd be able to use 
> it on a server-side java web app (Spring + Hibernate etc) project.  Ant 
> has everything that I would need to build an Ant version of a 
> SwitchTower recipe (at least I think it does), but I wondered if anyone 
> has an example build file for automatically deploying an app to [a] 
> remote server[s]
> 
> Check out latest code from SVN/CVS
> Compile (plus do hbm.xml generation etc)
> WAR
> (this is what I always do and never go beyond it to fully deploy the 
> application)
> 
> ssh remote server
> stop current version
> scp new WAR over to remote server
> start remote server
> run tests[2]
> 
> plus rollback to last working version if any tests fail
> 
> All these seem very possible with Ant (although a fair bit of work and 
> I'm used to manual deployment - but I'll concede that it'd be 
> wiser/better to automate it, hence my investigation)

If its all local, then look at Cargo for a set of ant tasks to start and 
stop the server. (its on codehaus somewhere)

If its remote, then Ant itself isnt geared up to work with remote file 
systems and the like. You can run Ant at the far end and have it do the 
work, using sshexec to run the build file you have just uploaded. It is 
doable, but gets complex fast, and is a dog to debug. Its easiest if the 
local/remote system share a file system and their clocks are in sync. If 
you run a risk of the clocks being out of sync, turn off all dependency 
logic in things like <copy> else you wont be able to update stuff properly.

> I seem to remember something about SmartFrog (Steve are you there?) 
> being more about this problem domain (managing multiple servers during 
> deployment etc)

That's right. There are two main problems with deployment (ignoring 
security and getting the stuff up there in the first plae)

-configuration : configuring all the bits to work together, so the 
database server has the right db and accounts for the app, the firewall 
has its ports open, the app server is listening on the right port, the 
webapp knows the port+login for the DB, etc.

-choreography: bringing up the bits of the system in the right order, 
shutting them down properly afterwards.

Smartfrog (http://smartfrog.org) tries to address both problems, 
securely. I'm actually working in my spare work time to do a cargo 
component, so that I can use cargo for basic start/stop/configure of the 
different app servers out there; smartfrog can handle the other bits 
like database, webapp itself, etc. I'm also exploring remote junit, 
treating junit itself as just something else to deploy on a set of 
remote boxes, collecting the reports elsewhere.

I'm going to warn you, automated deployment is not an easy thing to get 
right. SmartFrog's language for describing configurations to deploy is 
powerful, but like all OO-languages, complex, and the whole process of 
automating deployment from the command line/gui/ant is tricky. I would 
encourage you to come to the site, get the latest release and ask 
questions on our mailing list, we will do our best to help you.

Multiple servers comes easily once you have done one server, really. The 
hard part is changing how you deploy. I actually write 
deployment-centric code, stuff that is designed from the outset to be 
deployed and configured by smartfrog. It's a bit like how JBoss and 
Geronimo are built on JMX underneath; if you put management/deployment 
into the base architecture then its easier to manage and deploy.

-Steve
-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org