Ralph Goers wrote:
Steve Loughran wrote:
Simone Gianni wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would somehow assemble WARs
and EJB beans to make a working app, presumably through some GUI that
required the same work to be repeated every release.
If you are doing lots of late binding tuning to the WAR file, then
perhaps build time is the wrong place to do it; it should really be
done as part of the deployment process, where per machine
optimisations can go in. In this world what you want from the outset
is the exploded WAR, which is then taken with server-specific options
to create the target WAR for the target system.
Pardon me for saying so, but this is just nuts.
:)
In my environment our
CM folks do the build and then make it available for operations. Noone
after CM is allowed to modify the parts. Any modifiable configuration
has to be placed outside the webapp. Furthermore, CM prefers that no
exploded webapps be used, since it is much easier to distrubute wars.
ok. So where do the per-system modifications go in? do your war files
have hard coded assumptions about LDAP bindings, JDBC URLS or rely on
the app server to set up the JNDI bindings for all the info kept in your
dir server?
Next question: how do ops automate the 'provisioning' of the app server?
Do they have a piece of paper telling them what bits of the system you
need 'Redhat EL with Java 1.5.06 and the patches need to /etc/profile to
get it set up, or what services need to be running? Do you find that
they decide to try 1.5.09 without telling you? Or that they forget to do
something essential like bringing up the DNS server before the database
and app servers come up.
Because that's the kind of thing we can automate and lock down under
SCM. That lets us create a blank VMWare or Xen disk image, have it run a
PXE preboot to get the base image, then after it comes up we can bring
the system up to the state where the WAR file deploys.
In that world, you dont really need an opts team to deploy. You just
have a server that manages the build and deploy of the latest bit of the
SCM tree tagged as ready to go into production. It sticks it out every
night, and as server load increases, it brings up new machines. The ops
team take on a different role: managing the Xen/VMWare server farm,
monitoring the health of the (much larger) VM cluster, setting up the
approved system configurations. This is the stuff that Amazon EC2
presumably does behind the scenes -an outsourced ops team.
Like I said, I work on fairly advanced deployment problems. Tuning WAR
files is a detail.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
