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.

  • Building multiple Maven profiles for a single Jenkins job
  • CMake ExternalProject: how to specify relative path to the root CMakeLists.txt?
  • jenkins git webhook
  • How to configure custom maven project structure
  • Automated push “build branch” after using “git archive” without local repo
  • How to run Gulp from a webhook
  • 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?

  • Invoke Ansible playbook in Jenkins
  • Should you recreate containers when deploying web app?
  • Deployment of multi-project MVC4 solution to Azure fails
  • Call GitHub API with Travis to build Tag
  • Setting up Continuous integration and continuous deployment for Microsoft Applications
  • First GIT add of old system
  • 3 Solutions collect form web for “Jenkins – Promoting a build to different environments”

    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.

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.