I have a question that I sure has been answered a hundred times, I just see the solution clearly myself.
At my company, several environments exist for our web application:
Development - where new code is developed; volatile
Test - where initial testing is done; somewhat stable
Staging - where integration & load testing is done; stable
Production - multiple boxes; stable
My question is this...Ideally, we would deploy the same EAR in each environment. However, certain files that are specific to each environment exist that cannot be contained in the EAR file (log config files, etc).
I have some ideas on how to overcome this. I just would like to see how of others addressed this.
-
J2EE change management (3 messages)
- Posted by: Ryan Breidenbach
- Posted on: May 06 2002 15:53 EDT
Threaded Messages (3)
- J2EE change management by Tim Dawson on May 07 2002 08:28 EDT
- J2EE change management by Tim Dawson on May 07 2002 08:33 EDT
- J2EE change management by Ryan Breidenbach on May 07 2002 05:14 EDT
- J2EE change management by Tim Dawson on May 07 2002 08:33 EDT
-
J2EE change management[ Go to top ]
- Posted by: Tim Dawson
- Posted on: May 07 2002 08:28 EDT
- in response to Ryan Breidenbach
We use Ant and create different properties files for each configuration. These properties are mapped to filters and the config files are copied into our build directory using parameter substitution (e.g. @jsp.precompile@) and integrated into a war or ear from there.
Our build.xml contains these definitions:
<!-- setup build configuration -->
<property name="config" value="dev" />
<property file="build-${config}.properties" />
<property file="build.properties" />
<!-- define source directories -->
<property name="conf.src.dir" value="${basedir}/conf"/>
<!-- define build directories -->
<property name="build.dir" value="${basedir}/build"/>
<property name="conf.dir" value="${build.dir}/conf-${config}"/>
The main build.properties defines the standard properties. The default config is "dev" (what the developers use all the time) so a build-dev.properties file contains the default overrides or additions to those properties, likewise a build-test.properties would contain the properties for the test environment. (the order may seem backwards but its important in ant)
The files are copied from ./conf to build/conf-dev or build/conf-test, and the war task includes the files from whichever directory is appropriate.
One other thing that's important to do is to set the ant "overwrite" target when your build properties change so that the config files are re-copied. The following is an excerpt from our "prepare" target.
<!-- prepare conf dir by filtering defualt conf files -->
<filter token="cactus.baseurl" value="${cactus.baseurl}"/>
<filter token="jsp.option1.key" value="${jsp.option1.key}"/>
<filter token="jsp.option1.val" value="${jsp.option1.val}"/>
<filter token="jsp.option2.key" value="${jsp.option2.key}"/>
<filter token="jsp.option2.val" value="${jsp.option2.val}"/>
<filter token="jsp.option3.key" value="${jsp.option3.key}"/>
<filter token="jsp.option3.val" value="${jsp.option3.val}"/>
<filter token="config" value="${config}"/>
<!-- set overwrite flag if one of the build files changed -->
<condition property="overwrite.conf">
<not>
<uptodate property="overwrite.conf" targetfile="${conf.dir}/.touch">
<srcfiles dir= "${conf.src.dir}"/>
<srcfiles dir= "${basedir}" includes="build.xml,build.properties"/>
<srcfiles dir= "${basedir}" includes="build-${config}.properties"/>
</uptodate>
</not>
</condition>
<copy toDir="${conf.dir}" filtering="true" overwrite="${overwrite.conf}">
<fileset dir="${conf.src.dir}"/>
</copy>
<touch file="${conf.dir}/.touch"/>
Anyway, I hope this is helpful for you. It works great for us.
Tim Dawson
Lead Technical Architect
Notiva Corporation -
J2EE change management[ Go to top ]
- Posted by: Tim Dawson
- Posted on: May 07 2002 08:33 EDT
- in response to Tim Dawson
Whoops, I forgot to mention that in order to override the seemingly hardcoded config of "dev" you need to run ant with a command line option to set the property...
ant <target> -Dconfig=test
This overrides anything set inside the build.xml file. You can also add targets that do this for you, i.e. "ant buildtest" which sets config=test & calls its own build target. We do some of each (our autobuild uses a task that sets the config to "devauto" and calls several other targets. When we're doing a manual build we tend to use the command line.
Tim -
J2EE change management[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: May 07 2002 17:14 EDT
- in response to Tim Dawson
Thanks Tim. That is sort of the path we are, but you comments cast a little different light on it and gave me some new ideas.
Ant ROCKS!!!
Thanks.
Ryan