ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy Lambert <>
Subject Re: svnant - deploying from Subversion
Date Thu, 04 Nov 2010 17:53:02 GMT
Hello Michael,

I would personnally not want to deploy the webapp directly from 
subversion, although this can certainly work.
I would rather setup a build process and continuous integration and 
create a zip file or a war file from the sources in subversion.
You would need to use a continuous integration server (CruiseControl, 
Hudson, ...) and a repository to store the various versions of your war 
or zip file.
Ideally your web application should load the environment (server) 
dependent data from property files.
On my project we are generating the environment dependent property files 
from data stored in a LDAP server.
We have a custom schema with the property keys defined as attributes, 
and we create one entry (or one subtree) for each environment.
The script which generates the properties for one given environment uses 
property files templates and replaces the tokens in these templates with 
the values contained in LDAP.



On 11/4/10 11:45 AM, Ludwig, Michael wrote:
> Our web app source code is stored in Subversion. It's not Java, it's a script app. It
needs to be deployed to various servers, and some configuration data needs to be taken into
> There is no automation at the moment, but I'm about to change that. I'm presently cobbling
together a script to build patches for existing installations using the SvnAnt interface to
Subversion. Looks like it's got everything I need.
> I prefer patches because the entirety of the files in the site is simply too large.
> I think it's not too difficult to come up with a working concept of how state can be
determined and steps taken accordingly. State and steps? Well, let's say LIVE has a certain
version of the software deployed, which is basically a tag in SVN. In order to bring it up
to date, some rather trivial steps need to be performed, basically copy and delete, really
not much more in our case.
> I think my script just needs to know the pattern of the tag for a live version, then
find the most recent one (a tag containing a timestamp or something else that is sortable),
then determine the files that have been changed with respect to that tag, and also the deleted
files, then copy the updated files to the server, delete the deleted files on the server,
and perform any build action that might be required.
> Once I've made sure everything is deployed (maybe some checksumming), I can set the new
tag in the repository. Or rather, set the new tag beforehand, and then delete it if the deployment
goes wrong for some reason.
> Any thoughts on such a process you might want to share? Thanks!

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

View raw message