-----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 [email protected] as:
[email protected]
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: [email protected]
-----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 [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
