ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ferrer, Eric" <eric.fer...@transcore.com>
Subject RE: Regarding Continous build integration.
Date Wed, 22 Feb 2006 18:27:18 GMT
Rob,

I have only been in SF for Java Once conferences.

We have a similar setup with a default target that builds with no unit
test and deploys a war for production.  To give you a bit more detail of
what we are looking at for the next project/product life cycle. We will
be deploying 6 wars to one server running JBOSS instances on 3 different
ports and the same will be true for our test box.  I planned on testing
out several deployment techniques when I get a chance.  When using some
properties like databases, when deploying to websphere it was not an
issue since the datasource name was always the same and the connection
information was stored in websphere admin console.  I will not have that
easy as we move to a new persistence architecture.  Thanks for the info.

-Eric


-----Original Message-----
From: Anderson, Rob (Global Trade) [mailto:Rob.Anderson@nike.com] 
Sent: Wednesday, February 22, 2006 10:57 AM
To: Ant Users List
Subject: RE: Regarding Continous build integration.

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


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


Mime
View raw message