ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Jackson" <myspa...@gmail.com>
Subject Re: Trying to do things the "Ant way"
Date Fri, 28 Jul 2006 22:33:08 GMT
We have other setups that do have clustered stage and production
environments, so I'll file that one away for later. :-)

Thanks,
Jamie

On 7/28/06, Anderson, Rob (Global Trade) <Rob.Anderson@nike.com> wrote:
>
> This is great advice, and certainly one way to do the deploy-all. I
> would like to share another option...
>
> I once worked in situation where most of our environments were
> clustered, having two servers per environment. In this case I would
> create a "deploy-each" target, to deploy to one server, and wrap it with
> a "deploy" target using Ant-Contrib's <foreach> task to loop over the
> list of servers in the environment. If you write you build.xml as such,
> then "all" becomes just another environment with more servers in the
> list.
>
> Of course after, writing this up and realizing that you have different
> deployment processes (nfs,ssh) for different environment, this may not
> work so well for you. But now that I have written this, it would be a
> shame not to share it anyway.
>
> -Rob Anderson
>
> > -----Original Message-----
> > From: Andrew Goktepe [mailto:andrewgoktepe@gmail.com]
> > Sent: Friday, July 28, 2006 9:05 AM
> > To: Ant Users List
> > Subject: Re: Trying to do things the "Ant way"
> >
> > There is a loss of performance when you use antcall in large,
> > complex builds. It also makes target dependencies less clear.
> > But it's the only way I know of to call a specific target
> > based on a value obtained at runtime. In most other cases,
> > it's much better to use the 'depends'
> > attribute of 'target' with the exact target names.
> >
> > To achieve a deploy-all case, you could have a separate
> > target (optimally in a separate script) that makes 'ant'
> > calls into the main deployment script:
> >
> > <target name="deploy-all">
> >     <ant antfile="mydeploymentscript.xml" inheritAll="false">
> >         <property name="envname" value="stage" />
> >     </ant>
> >     <ant antfile="mydeploymentscript.xml" inheritAll="false">
> >         <property name="envname" value="integ" />
> >     </ant>
> >
> >     ... etc
> > </target>
> >
> > -Andrew
> >
> > On 7/28/06, Jamie Jackson <myspamb8@gmail.com> wrote:
> > >
> > > Thanks for the quick response. I have a couple of follow-ups.
> > >
> > > I've gotten the impression from reading other posts that
> > <antcall> is
> > > to be avoided, so I'm wondering about its use here.
> > >
> > > The other question I have is: How would I satisfy the
> > deploy-all use
> > > case while reusing as much of the script as practical?
> > >
> > > Thanks again,
> > > Jamie
> > >
> > > On 7/28/06, Andrew Goktepe <andrewgoktepe@gmail.com> wrote:
> > > >
> > > > Oops. s/<properties file/<property file/
> > > >
> > > > On 7/28/06, Andrew Goktepe <andrewgoktepe@gmail.com> wrote:
> > > > >
> > > > >  We use a separate properties file for each
> > environment, and have
> > > common
> > > > > property names. Instead of integ.transfertype,
> > stage.transfertype,
> > > etc,
> > > > I
> > > > > would just have 'transfertype' and it would have
> > different values
> > > > > in
> > > the
> > > > > different files. Then the Ant script has targets based on the
> > > > > possible values of the property, and one generic parent
> > target that calls them.
> > > > >
> > > > > Example:
> > > > > <properties file="${envname}.properties" /> <target
> > name="deploy">
> > > > >     <antcall target="deploy-${transfertype}" />
> > </target> <target
> > > > > name="deploy-nfs"> ... </target> <target name="deploy-ssh">
...
> > > > > </target>
> > > > >
> > > > > envname determines which environment-specific properties file
> > > > > needs to
> > > > be
> > > > > read.
> > > > >
> > > > > This is a more scalable solution. Adding a new environment is as
> > > simple
> > > > as
> > > > > creating a new properties file.
> > > > >
> > > > > This assumes the build has already occurred and you can
> > make run
> > > > > the deployment Ant script separately for each environment.
> > > > >
> > > > > -Andrew
> > > > >
> > > > > On 7/28/06, Jamie Jackson <myspamb8@gmail.com> wrote:
> > > > > >
> > > > > > I'm having a problem trying to grok the "ant way" to
> > do things
> > > > > > (i.e
> > > .,
> > > > > > without conditionals). I just got started with Ant a
> > couple days
> > > ago,
> > > > so
> > > > > >
> > > > > > take that into consideration.
> > > > > >
> > > > > > I'm trying to produce a well-factored script to handle code
> > > deployment
> > > > > > to
> > > > > > remote servers.
> > > > > >
> > > > > > Tasks:
> > > > > > *  deploy-integ
> > > > > > *  deploy-stage
> > > > > > *  deploy-prod
> > > > > > *  deploy-all (all of the above)
> > > > > >
> > > > > > Here's the problem: Depending on the set of servers, some are
> > > > available
> > > > > > via
> > > > > > SSH, others are available via NFS, and I'd like the
> > script to be
> > > > > > generalizable enough to specify the transfer type in the
> > > > > > properties file, along with the (potentially) varying paths
> > > > > > among servers.
> > > > > >
> > > > > > Here's a stab at the properties file:
> > > > > > -----------------------------------
> > > > > > svn.url=http://myhost/myrepos/myproj
> > > > > >
> > > > > > integ.transfertype=nfs
> > > > > > stage.transfertype=ssh
> > > > > > prod.transfertype=ssh
> > > > > >
> > > > > > # a nfs basepath would look like //webdev/websites # an ssh
> > > > > > basepath would look like username@hostname:/path/to/docroot
> > > > > > integ.basepath=//devserver/docroot
> > > > > > stage.basepath=username@hostname :/path/to/docroot
> > > > > > prod.basepath=username@hostname:/path/to/docroot
> > > > > >
> > > > > > integ.proj.wwwroot=childwelfare
> > > > > > stage.proj.wwwroot=childwelfare
> > > > > > prod.proj.wwwroot=childwelfare
> > > > > > ---------------------------------
> > > > > >
> > > > > > Here are a couple of the salient tasks (see inline comments):
> > > > > >
> > > > > >    <target name="deploy-integ">
> > > > > >        <deploy basepath="integ.basepath" proj.wwwroot="
> > > > > > integ.proj.wwwroot"
> > > > > > transfertype="integ.transfertype" />
> > > > > >    </target>
> > > > > >
> > > > > >    <macrodef name="deploy">
> > > > > >        <attribute name="args" />
> > > > > >        <attribute name="basepath" />
> > > > > >        <attribute name="proj.wwwroot" />
> > > > > >        <attribute name="transfertype" />
> > > > > >        <!-- I'd like to do it the "right way, and avoid "if",
> > > > > > but
> > > > don't
> > > > > > know how -->
> > > > > >        <!-- Not to mention that I can't even put the "if"
in
> > > macrodef,
> > > > > > so
> > > > > > it doesn't work anyway -->
> > > > > >        <if>
> > > > > >            <equals arg1="@{transfertype}" arg2="ssh" />
> > > > > >            <then>
> > > > > >                <property name="@{args}" value="-e ssh
> > -Cacvz @{
> > > > > > local.buildDir}/* @{basepath}/@{proj.wwwroot}" />
> > > > > >            </then>
> > > > > >            <else>
> > > > > >                <property name="@{args}" value="-av
> > > > > > @{local.buildDir
> > > }/
> > > > > > @{basepath}/@{proj.wwwroot}/" />
> > > > > >            </else>
> > > > > >        </if>
> > > > > >        <echo message="rsync ${args}" />
> > > > > >        <exec executable="rsync">
> > > > > >            <arg line="${args}" />
> > > > > >        </exec>
> > > > > >    </macrodef>
> > > > > >
> > > > > > What's the right approach?
> > > > > >
> > > > > > Thanks,
> > > > > > Jamie
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message