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
http://ant.apache.org/ant_in_anger.html)
Also: by the same author,
Making Web Services that work:
http://www.hpl.hp.com/techreports/2002/HPL-2002-274.html
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
control)
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
workflow.
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
deployment.
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 (http://smartfrog.org)
is one option. Others are
-the premium big-system management tools like the Microsoft Datacenter
thing,
-linux rpms (that is, package everything as rpms and use your server's
RPM tools to install stuff).
-cfengine (unix/linux only)
-bcfg
-lcfg (lcfg.org)
Large-Scale CM is still a research topic. 3 machines is solved. 500+
nodes is considered leading edge.
http://config.sage.org/faq.html
http://homepages.informatics.ed.ac.uk/group/lssconf/
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.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
