ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anderson, Rob (Global Trade)" <Rob.Ander...@nike.com>
Subject RE: Regarding Continous build integration.
Date Wed, 22 Feb 2006 17:57:12 GMT
I think you are talking about adding a default behavior so that if no
args are passed the production release is created. This can be done by
adding another target like this...

<target name="set.default" unless="env">
  <property name="env" value="prod"/>
</target>

Then make the other targets depend on this one. If ${env} is passed in
on the command line, this target will not run, otherwise ${env} will be
set to your chosen default value. Doing this, you will have to be
carefull where you put the <property file="${env}.properties"/> to be
sure that the ${env} property is set.

Another option is to prompt for the value of ${env} on the command line
with the <input> task. Using the input task, you could specify valid
input args and even a default, hopefully reducing the possibility for
someone to screw it up.

Your name looks familiar. Did you used to work at NextCard in SF?

-Rob Anderson

> -----Original Message-----
> From: Ferrer, Eric [mailto:eric.ferrer@transcore.com] 
> Sent: Tuesday, February 21, 2006 2:58 PM
> To: Ant Users List
> Subject: RE: Regarding Continous build integration.
> 
> Rob,
> 
> Is there anyway to do what you described all at once with out 
> providing the arguments?  
> 
> For example, I want to provide 3 targets (build all, build 
> with unit testing, build static content only)
> 
> I would then like to generate a war file for dev, test, and 
> prod with appropriate properties file in them in one pass.  I 
> guess I am looking for the best practice approach.  Currently 
> I control the builds on dev, but test and prod will be done 
> by third party vendors.  I would like to prevent them from 
> having to pass different arguments as I know that one day 
> they will mess it up and deploy the wrong thing.  This would 
> lead to me having to figure out that they are connecting in 
> production to a dev database using dev config throughout the system.
> 
> Thanks in advance
> -Eric
> 
> -----Original Message-----
> From: Anderson, Rob (Global Trade) [mailto:Rob.Anderson@nike.com]
> Sent: Tuesday, February 21, 2006 3:20 PM
> To: Ant Users List
> Subject: RE: Regarding Continous build integration.
> 
>  
> 
> > -----Original Message-----
> > From: Steve Loughran [mailto:stevel@apache.org]
> > Sent: Saturday, February 18, 2006 2:24 PM
> > To: Ant Users List
> > Subject: Re: Regarding Continous build integration.
> > 
> > Ferrer, Eric wrote:
> > > This topic brings up an interesting issue I am having and 
> maybe the 
> > > community has the answer.  I have a local build for 
> tomcat and our 
> > > development environment (properties files are the same,
> > information to
> > > connect to our databases the same).  However, the problem 
> lies with 
> > > deploying to JBOSS our QA environment and our Websphere QA
> > environment.
> > > The wars from the dev build after validated either get
> > moved over and
> > > then the QA environment is talking to dev database, or 
> after moving 
> > > the war, the properties files are migrated over that point
> > to test and
> > > the war is rebuilt.  (QA is out of my control)
> > > 
> > > I feel there has to be a better way to deploy across application 
> > > servers and/or at least be able to fun a build for dev,
> > test, and prod
> > > that use the appropriate properties files for each
> > environment in the war.
> > > 
> > 
> > oh yes. but its complex, currently complex enough that only 
> once you 
> > have tens of machines do people bother to automate it.
> > 
> > the problem is really the difference in configuration 
> between systems 
> > stops you just moving things around.
> > 
> > 
> > -have a different properties file for each hostname, -use LDAP to 
> > configure every cluster -use smartfrog ( http://smartfrog.org/ ) to 
> > merge deployment and configuration. (I'm part of this project)
> > 
> > Properties files just dont scale.
> > 
> > -steve
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
> additional 
> > commands, e-mail: user-help@ant.apache.org
> > 
> > 
> > 
> 
> Using different properties files for each hostname or 
> environment is a good idea. I have had great success in the 
> past with using the <replace> task combined with an 
> environment or host specific properties file and a template 
> that is used to generate the actual config files that get 
> deployed. So for example, you may have a file called 
> databaseconnection.properties.template that looks like this...
> 
> ConnectionString=_ENVConnectionString_
> 
> Then you would have a properties file for each environment 
> that looks like this...
> 
> dev.properties
> ===============
> _ENVConnectionString_=jdbc:blahblahblah:host_a
> 
> qa.properties
> ===============
> _ENVConnectionString_=jdbc:blahblahblah:host_b
> 
> 
> So then in your build.xml you would copy 
> databaseconnection.properties.template to 
> databaseconnection.properties and use the replace task to 
> populate the ConnectionString property with the correct value 
> for the environment. Run Ant with the following command to 
> pass in the environment as a property.
> 
> ant -Denv=dev
> 
> Then in your build.xml you would have something that loads 
> the properties from the right file...
> 
> <property file="${env}.properties"/>
> 
> I the case where you are using different servlet engines, you 
> may need to use a completely different set of properties 
> files. You may just decide to version a set of config files 
> for each environment with the correct values already 
> populated. Then simply use the ${env} property to decide 
> where to find the config files to include in your app.
> 
> -Rob Anderson
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
> additional commands, e-mail: user-help@ant.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
> additional commands, e-mail: user-help@ant.apache.org
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message