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.
Regards,
Antoine
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 account.
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.
http://subclipse.tigris.org/svnant.html
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: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
