Re: Jahia Deployments

On Thursday 10 April 2008, Michelle Michael wrote:
> I am seeking tips from experienced Jahia users on three areas around
> deployments:
> 
> 1. Tracking Configuration Tweaks - 
> Do any of you have a recommended process for keeping track of/backing up
> all the files that get changed over time for configuring and tweaking
> production servers (jahia.properties,
> applicationcontext-basejahiaconfig.xml, etc)? 

We have a seperate directory which contains "touched" configuration
files with the same directory path then in the original distribution.
On startup these changed files get copied to the original distribution.

This way you can do:
- Have only the changed files in a version control
- Deploy a distribution update without caring about changed config files
- For those not familiar with the installation it is clear which files
  have some special configuration (e.g. backup system admins)

> 2. Rollbacks - 
> What methods are you all using for rolling back code changes? We have
> all of our template and java integration code in version control, but
> removing deployed files and redeploying seems error-prone. And a newly
> untarred jahia install with a new integration jar each time seems a bit
> heavy-handed. What are your experiences with rollbacks? Suggestions?

If you fiddle with seperate files in the deployment it is not error-prone as long
as you follow a certain process consequently. Since deploying a whole war
file means a longer down time that's not the preffered way in our installations.

We have the whole Jahia deployment in a seperate version control module.
The adapted templates will be mirrored in three positions: var/shared_templates,
var/new_templates/<virtual-site-key>, jsp/jahia/templates/<virtual-site-key>.
The first one is for the fresh install of a virtual site, the second for heavier changes and
added templates in an existing site, the thrid one for "hotpatching" templates in use.

The build process is:
- Build application jars and check in to the deployment module
- Build template jars and check in to the deployment module
- Tag deployment module

The deployment process is:
- Stop application, if needed0
- Check out deployment module by tag
- If you don't have the webapp under version control directly you can
  use "rsync -a --delete ..." 
- Start application, if needed

If you just have smaller changes to the templates in use, e.g. some UI text, than you
can follow the same process but don't need a restart. In Jahia the automatic deployment
of new template jars should be switched off. Only use this deployment if needed, e.g. 
when heavy changes occur (a lot of new templates, new resource bundles)

> 3. Deployments in a Clustered Environment - 
> We have a working initial configuration of clustered nodes with
> integrated templates and custom java, but are trying to work out the
> best way to approach deployments for code changes/new templates. I found
> a PDF, Jahia_Clustering_HOW-TO_v2.pdf for Jahia 4.0.5 that says some
> templates/webapps deployment work needs to be done manually. In
> particular, it recommends dropping in a jar/war on the fist server and
> then manually copying the deployed files to the others servers in the
> cluster. Does anyone know if Jahia 5.0.3 in a cluster will support
> dropping in a jar on all servers? For those in a clustered environment,
> what deployment process is working for you? Also is there a newer
> version of this how-to document?

No idea. The only tip I have here: Don't do it, except you have a good
reason for it, because the complexity more than doubles. MP systems
are cheap and if you just have relatively static content and a low
amount of dynamically rendered content (e.g. search results) you can
work with proxy servers or even a static mirror.

Best,

Jens
_______________________________________________
dev_list mailing list
[email protected]
http://lists.jahia.org/cgi-bin/mailman/listinfo/dev_list