Hi Chris
It seems like you guys have a pretty good setup going, better than the
one at my (current) company anyway. I didn't realise that your
environment doesn't have dependencies on statically linked war files
like ours does. The developer makes a release and creates the three wars
for deployment at the same time, which then have to be kept in synch. I
have a lot of issues with this process as it's very error-prone, and I
think some of my attitude towards this process crept into my previous
emails, which wasn't appropriate. my bad.
Unfortunately not all of us are lucky enough for the prod server to have
access to the version control repository...;-p
Also, our situation is a bit different where we consult to the client,
our two networks are totally separated so there's no way that we can do
fresh builds from version control (Subversion rocks!) to deployement
targets directly. We need to build the wars in our office, then submit
them to the client for testing and promotion. We have very little
control over the promotion process, and more than once we've had serious
bugs resulting from the wrong war going into the wrong target due to a
mistake by the clients sysadmin. Thus my attitude towards configuration
being external to the app as much as possible, I like to build a
stand-alone war that gets as much of their info as possible from the
container/database.
responses inline.
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt,
I disagree with many of your assertions.
well put.
I'm guessing that you don't deploy all 3 WARs onto the same machine.
What's the difference between 3 different WARs and 1 WAR in 3 places?
Don't complain about disk space when the argument is 1) flawed (disk
space doesn't matter) and 2) moot (deployments to different servers).
fair point, HD space isn't an issue. it's the process used to deploy the
war to the server, and ensuring that the same release is delivered
consistently across all targets. so long as the code can be deployed
consistely & transparent of the target that's the main thing as I see it.
I completely disagree. We have complex configurations that need to
change for each environment (many properties files, etc.). Trying to
create one properties file to rule them all is impossible, and shoving
all that configuration into a (static) deployment descriptor on the
target server is kludgy and error prone, since the developers don't have
control over the server configuration.
sorry, I should have been more specific, I was just referring to
database targeting, not the complete environment. there's a lot of
things that ant <replace> is excellent for.
We don't deliver a WAR file to our deployment team; we give them a cvs
tag to use as the new version. It's as simple as:
$ pushd
$ cd $APP
$ ant tomcat-stop
$ ant install-clean
$ popd
$ rm -rf $APP
$ cvs checkout -r ${RELEASE_TAG} ${APP}
$ cd ${APP}
$ ant install
$ ant tomcat-start
You may find that complicated, but it's all that's required for us to
deploy our applications into ANY environment.
nice. fresh checkout from cvs tag straight into deployment. is good!
Wanna upgrade Tomcat? No
problem:
# cd /where/you/want/tomcat/to/live
# tar xzf apache-tomcat-version.tar.gz
# (fix 'tomcat' symlink)
# (restart apps at your convenience)
No effing around with Tomcat server configuration. In fact, deploying
our production applications doesn't require root access, so out
deployment team can't really break anything.
nice.
- -chris
--
Matthew Kerle
IT Consultant
Canberra, Australia
Mobile: +61404 096 863
Email : [EMAIL PROTECTED]
Web : http://threebrightlights.blogspot.com/
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
