-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We handle deployment to our servers as follows:

We have 8 servers total 2 dev (cas dev use only), 2 test (developer
dev/test), 2 stage (development stage), 2 prod (self explainitory). I
set an environment variable (TIER) on each tier appropriately, and I use
the external config options to include config files *OUTSIDE* the WAR
that hold the DB connect passwords, the LDAP server names, etc --
anything that varies between tier.

We have a shared filesystem mounted on all hosts: /shared_data.

Every host has tomcat installed (pretty much untar the apache tar file),
and the dev hosts have maven and the cas source.

Once a version of CAS is ready to start deploying, the cas.war is copied
to /shared_data/cas/`date -I`/ from the dev hosts. (I also copy all the
files modifed for the overlay, so I can revert to a point in time if
needed).

I then modify symlinks to point from /shared_data/cas/${TIER} to a given
 version of our cas.war. Once that is done for a tier, I can run a quick
script that copies from /shared_data/cas/${TIER} to
${TOMCAT_HOME}/webapps, and restarts tomcat.

This works out *very* slick, as we can update test, stage, and prod as
testing completes, and allows us to see in a glance what versions are
deployed where -- and by backing up symlinks before I update them, I can
also track the history of what was moved when -- and rollbacks are a
breeze -- just restore the symlink of the version that works, and re-run
the script.

I like this for a few reasons:
1) I only have the build tools installed where they are absolutely needed
2) I only maintain 1 version of the code in one location, which means
that it is easier to ensure everything is identical inside CAS
3) This allows me to crank logging on dev/test as high as I wish, and
not worry about accidentally exposing production passwords.
4) I can *change* values with a simple restart of the nodes, rather than
a full rebuild, if I need to adjust a config option such as log levels,
or db connect info or pool sizes, etc.

Jeff

Raymond D Walker wrote:
> Our institution's ยข2:
> 
> We currently use the Maven 2 overlay, but have opted to modify the pom.xml 
> and add a few properties files to allow for multiple environments. This is 
> done via enabling a particular build profile that would filter multiple 
> environment specific variables accordingly.
> 
> We also run 3 environments (2 servers prd, 2 servers test, 1 server dev) 
> where the deployment procedure involves locally pulling down the codebase 
> from a local repository, building specifically for the env via the procedure 
> mentioned above, then deploying. Speeds up things greatly. 
> 
> Raymond Walker
> Software Systems Engineer Sr.
> ITS Northern Arizona University
> 
> On May 5, 2010, at 10:08 AM, Jeff Chapin wrote:
> 
> I'll second this.
> 
> 
> Marvin Addison wrote:
>>>>> The benefit of the method described in the Clustering docs is that you 
>>>>> pull
>>>>> the configuration out of the war file, and make it host specific, and you
>>>>> can roll the same war file to all servers in the cluster.
>>>> +1 for this approach.  We are _very_ happy using a single deployable
>>>> across 6 servers (2 for each of dev, pprd, prod).
>>>>
>>>> M
>>>>
> 
>>
- --
You are currently subscribed to cas-user@lists.jasig.org as:
ray.wal...@nau.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

- --
Jeff Chapin,
Assistant Systems/Applications Administrator
ITS-IS, University of Northern Iowa
Phone: 319-273-3162 Email: jeff.cha...@uni.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvh2fsACgkQQiaEUfQoY7Sp9gCgh8c41LSvq6wWxUV3DMTgknLm
v/4AoIsxkhvUHX/f7wY2gb8pNYKHMtL9
=2/d+
-----END PGP SIGNATURE-----

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to