Jenkins - Promoting a build to different environments

Question

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, test, 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?

Answer 1

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.

Answer 2

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.