Answers: <p>You can create a release process to manage deployments in your environments.
  A plugin that can help you is the <a href="http://maven.apache.org/maven-release/maven-release-plugin/" rel="nofollow noreferrer">maven-release-plugin</a>, where you 'freeze' the package and can promote them between environments (DEV -> UAT -> PROD). This ensures that the artifact (package) is exactly the same as the Production environment.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-09-17T21:21:37.383Z
Answers: 2018-09-17T21:21:37.383Z
Answers: dalmo.santos
Body: <p>We use <code>Jenkins</code> for CI. The app is written in <code>Java</code>, built with <code>Maven</code> (invoked manually in local dev environments and by Jenkins), deployed on various <code>Tomcat</code> servers. Nothing unusual about the application stack. Version control is <code>SVN</code> for the time being (we're looking at <code>Git</code> and I hope that comes soon).</p>
  
  <p>We have a multi-phase Jenkins job called something like <strong>build.all</strong> which does <code>svn update</code> using the Maven plugin and then runs <code>mvn clean install</code> from the root dir where the code is checked out by svn. Then, another set of jobs deploys the artifacts made by <strong>build.all</strong> using <a href="https://wiki.jenkins.io/display/JENKINS/Deploy+Plugin" rel="nofollow noreferrer">deploy plugin</a> by sending them over to the target servers using a Tomcat manager web service. The deploy jobs specify the latest successful build of <strong>build.all</strong> as the source of artifacts to deploy.</p>
  
  <p>That works great when we are in a single branch mode. The hard setting of <strong>build.all</strong> 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.</p>
  
  <p>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 <em>STAGE</em> or <em>UAT</em>, Jenkins looks up which build job (specific to a branch) is mapped to that environment?</p>
  
Tags: <jenkins><branch><subversion>
Title: Alternating VC branches to build deployment artifacts for different environments
UserDisplayName: amphibient
ThreadText: # Alternating VC branches to build deployment artifacts for different environments
  
  (Asked by: username_0 on 2018-06-26)
  
  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](https://wiki.jenkins.io/display/JENKINS/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?
  
  **Tags:** jenkins, branch, subversion
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-09-17. Score: 1
  
  You can create a release process to manage deployments in your environments.
  A plugin that can help you is the [maven-release-plugin](http://maven.apache.org/maven-release/maven-release-plugin/), where you 'freeze' the package and can promote them between environments (DEV -> UAT -> PROD). This ensures that the artifact (package) is exactly the same as the Production environment.
  
  
  ---
  
  