Re: Maven Build and Deploy Best Practices

Fri, 27 Jan 2012 08:57:40 -0800 

On 01/27/2012 05:33 PM, Carlucci, Tony wrote:

-----Original Message-----
From: marijan milicevic [mailto:[email protected]]
Sent: Friday, January 27, 2012 10:58 AM
To: [email protected]
Subject: Re: Maven Build and Deploy Best Practices

Hi Tony,

On 01/27/2012 04:38 PM, Carlucci, Tony wrote:

Hello,



We have been trying to determine the best way to build and deploy Rave

based projects internally (in reality Maven 3 projects).   Our current software
migration process requires us to build a "generic" artifact of any application
(without any environment specific properties) that can be deployed to any of
our environments (dev, qa, prod, etc).   The deploy process essentially
retrieves the generic artifact and applies the environment specific settings
(like urls to external resources, email addresses, LDAP urls, etc), and copies
the environment-specific WAR to the appropriate server.



The majority of our applications are Ant based and we have a neat home-

grown Task that performs string token substitutions of our files which contain
placeholders for the environment specific values.  This lets us customize any
file in our application (.properties, application-context.xml, web.xml, etc)
during the deploy process.



Our question is:  how do we best do this for Maven 3 based projects?  We

need to build the "generic" artifact (which gets stored in our Software
Repository application) and then apply the environment specific properties at
deploy time.  I know Maven supports profiles but these seem to be needed
during the build/packaging phase, and would undoubtedly place an
environment specific artifact in both the Maven repository and our internal
artifact repository tool.   Is it better to externalize all environment specific
properties outside of the WAR?
we (at Hippo) mostly use this approach: storing stuff outside of the WAR
(albeit for different product). What we try to avoid is to many
differences within appication-contex, web.xml etc. files and use
properties as much as possible, actually, in most cases those files are
identical for all environments.

A lot of the security issues is also solved by applying this (e.g. no
user names nor passwords are stored on developers machines /svn/git etc).
I think Rave can pretty much be used this way.

cheers
marijan



Thanks  for the input Marijan.  A few follow up questions:

1) How do you reference the external properties file from the application?  
Would you reference it from, say, a spring properties bean config that 
references it via file: instead of classpath?  (like 
file://directory/outside/webapp/thatsonallourservers)
I'll need to ask our sys admins, but I believe it is a combination of symbolic links/system wide properties and application server properties (think of JNDI, e.g. mail/Session deffinition, tomcat/conf/context.xml file etc) 



2) How do you manage these files from a version/source control perspective?  Do you store 
them in a separate sub-folder of the project that is not used at all by your package 
mechanism (meaning ant or maven does use/see these files at all)?  Do you keep multiple 
environment-specific versions of your properties files around, or do you have some 
process that takes a single "template" and applies the environment specific 
values to them
we only store things needed for local development. We have some configuration stored into our local repository which is meant for production/test servers, but his part is very Hippo (our CMS product) specific. 



3) How do you deploy the files if they change?  Do you deploy them separately 
from your WAR deploy process?
no. normally some properties rarely change (like DB connection stuff etc.). Application specific properties are mentioned in release notes. So, yes, there is a "human factor" involved e.g. you need to keep release notes updated. 


I am also interested how other people are dealing with this issues..

cheers,
marijan






This seems like a problem that has already been solved and we are hoping

the Rave community would have some experience in this area.



Thanks, Tony

Reply via email to