Z W wrote:
Steve L
Thanks for your response.
Sounds like another huge learning curve for me.
Is there any other way in Ant besides having to learn sf ?
I'm unsure if I have the time bandwidth to experiment with.
1. If you can use conditions to check for the remote state, then you can
do stuff too. Here's some of my ant-based deployment tests that probe a
URL using <waitfor> and then run some <get> operations until my test
pages are happy
<target name="wait" depends="deploy-properties">
<fail unless="application.url" >No application.url defined</fail>
<property name="deploy.sleep" value="5"/>
<property name="deploy.waittime" value="20" />
<sleep seconds="5"/>
<waitfor maxwait="${deploy.waittime}"
maxwaitunit="second">
<http url="${application.url}" />
</waitfor>
</target>
<target name="wait-undeploy" depends="undeploy">
<property name="undeploy.waittime" value="10"/>
<waitfor maxwait="${undeploy.waittime}"
maxwaitunit="second">
<not>
<http url="${application.url}"/>
</not>
</waitfor>
</target>
<target name="get" depends="deploy,wait">
<get src="${application.url}happy.jsp"
dest="${build.dir}/happy.html"/>
<get src="${application.url}feed/"
dest="${build.dir}/feed.xml"/>
</target>
<!--this is our state-->
<target name="deployed" depends="get"
description="the application is in a deployed state"/>
<target name="undeployed" depends="undeploy"/>
As well as <http>, there's a <socket> condition that looks for a port
being open on a local/remote machine
2. Puppet, by Luke Kanias, is another (ruby-based) configuration
management tool. Unix only; good a low level system config management,
but not so good at Java application configuration.
3. Build and publish your own RPM/deb files.
On linux, you can use the <rpmbuild> task to create new RPM files; you
can then <scp> up these RPMs, and install them -or push them out to a
server farm using yum or similar. This lets you manage hundreds of
machines, machines that must be set up to pull down files from your
central repository
RPMs can run code at install/uninstall time, so can start and stop
services. They are very, very hard to get right though, especially
robust uninstall scripts. I've found it easier to not put any scripts
there and require the users to shut things down cleanly.
4. Write complex scripts and run them on the remote boxes
for this to work best, I'd encourage you to move away from bash or
similar, and push out Ant, Perl or Ruby files to the remote boxes, and
run them there. If you use Ant, there are some Remote Ant tools that you
can search for; I think ant.apache.org covers them. Its much easier for
a build file on the remote system to test stuff and act on it, than it
is for a local build file to try and manage it. If you are deploying to
app servers, you already have enough of a JVM installed to host ant...
I'm slowly building up a set of articles on deployment/configuration on
a wiki:
http://wiki.smartfrog.org/wiki/display/sf/Patterns+of+Deployment
Have a look if you have some time.
-steve
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
