We use Jenkins for CI. The app is written in Java, built with Maven (invoked manually in local dev environments and by Jenkins), deployed on various Tomcat servers. Nothing unusual about the application stack. Version control is SVN for the time being (we're looking at Git and I hope that comes soon).
We have a multi-phase Jenkins job called something like build.all which does svn update using the Maven plugin and then runs mvn clean install from the root dir where the code is checked out by svn. Then, another set of jobs deploys the artifacts made by build.all using deploy plugin by sending them over to the target servers using a Tomcat manager web service. The deploy jobs specify the latest successful build of build.all as the source of artifacts to deploy.
That works great when we are in a single branch mode. The hard setting of build.all as the source of artifacts to deploy is what is giving me headaches while trying to support transition periods during which some environments receive deployments from branch X and some from branch Y.
Without belaboring you with the minutiae of random low level tactics I'm speculating might make this possible -- can you recommend a high level strategy to support parallel artifact builds from different versioning branches? One goal is to not have to change the job source of artifacts to deploy because there is a rather large number of jobs that do deployments and changing them all by hand would be prohibitively labor intensive. For example, is there a way to maintain a key lookup mapping environments with source branches (or references thereof) so if a deployment job starts with STAGE or UAT, Jenkins looks up which build job (specific to a branch) is mapped to that environment?
