Jenkins - Promoting a build to different environments

I was hoping for some guidance on the best way to promote a build through its environments.

We have 3 environments, DEV, STAGING, PROD.

The DEV Jenkins build is running in a continuous integration set-up, as code is checked in to subversion, Jenkins will run a new build (clean, compile, test, deploy).

The tricky bit is when it comes to STAGING and PROD.

The idea was to be able to manually promote a successful DEV build to STAGING. STAGING build would check out the DEV's SVN Revision number, build, te开发者_JS百科st, deploy to staging and finally create a branch in SVN.

Lastly the release manager could manually promote the STAGING build to PROD. PROD build would check out the branch from the previous STAGING build, deploy to PROD and tag the branch as a release.

I have tried to use a combination of the Promotion Builds Plugin and the Paramterized Trigger Plugin but with no luck. The Subversion Revision number doesn't seem to get passed between DEV build to STAGING build.

Does anyone have any guidance on their process to promote a build through multiple environments?

Another approach is to make use of the Artifact storage Jenkins provides coupled with the Copy Artifact Plugin.

1. When a build is completed, you could instruct Jenkins to persist your application, either as a compressed zip/tar.gz or as an application bundle (jar/war)
2. Trigger a downstream job and use the Copy Artifact to retrieve the recorded artifact from the upstream job (or use parameterised builds)
3. Deploy/Unzip artifact as necessary - Build shell script/maven deploy?
4. Retest application using the same sources/binaries as was created in step 1
5. Repeat for PROD as necessary

This approach would allow you to fingerprint the artifacts, and thus Jenkins would link builds together in the UI, as well as allow more formal sign off.

In this scenario, why do you need to go back and label the branch in svn? We don't use svn, but w/ TFS, when Hudson/Jenkins gets the code, the changeset number it has retrieved is in the build log. So we know what code the build came from, and could get back to it at any time.

Then we promote the build from environment to environment using Hudson, the source control system doesn't need to know where the code is deployed.

If it's absolutely necessary to store the SVN Revision ID, then add a build step to your DEV job that copies it to a file. Something like this:

echo %SVN_REVISION%>revision.ini

or something like this:

echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini

Then artifact revision.ini. When doing a STAGING build, use the Copy Artifact plugin (as mentioned by a previous user) to retrieve the revision.ini file specific to the build and load it into a variable. Then use that variable in a command line call to "svn" to build the tag.