Tim Pizey from Tim Pizey
We have a prototypical webapp platform which has four variants, commodities, energy, minerals and wood. We use the Maven war overlay feature. Don't blame me it was before my time.
This architecture, with a core platform and four variants, means that one commit to platform can result in five staging sites needing to be redeployed.
We have a fairly mature Continuous Integration setup, using Jenkins to build five projects on commit. The team is small enough that we also build each developer's fork. Broken builds on trunk are not common.
NB This setup does deploy broken builds. Use a pipeline if broken staging builds are a problem in themselves.
Of Martin Fowler's Continuous Integration Checklist we have a score in every category but one:
Continuous, Unchecked, Deployment
Each project has an executable build file redo:
mvn clean install -DskipTests=true
which calls the deployment to tomcat reload
service tomcat7 stop
rm -rf /var/lib/tomcat7/webapps/ROOT
cp target/ROOT.war /var/lib/tomcat7/webapps/
service tomcat7 start
We can use a githook to call redo when the project is updated:
ln -s ../../redo post-merge
Add a line to chrontab using
*/5 * * * * cd checkout/commodities && git pull -q origin master
This polls for changes to the project code every five minutes and calls redo
if a change is detected.
However we also need to redeploy if a change is made to the prototype, platform.
We can achieve this with a script continuousDeployment
# Assumed to be invoked from derivative project which contains script redo
git fetch > change_log.txt 2>&1
if [ -s change_log.txt ]
# Installs by fireing githook post-merge
git pull origin master
which is also invoked by a crontab:
*/5 * * * * cd checkout/commodities && ../platform/continuousDeployment