Jenkins Pipeline for Continuous Delivery and Deployment

DZone 's Guide to

Jenkins Pipeline for Continuous Delivery and Deployment

Review the principles of continuous delivery and deployment, and learn how you can apply them by using your Jenkins pipeline as code.

· DevOps Zone ·
Free Resource

Before we show how we can apply continuous delivery and deployment using Jenkins pipeline as code, we need to refresh our mind about the difference between continuous integration, delivery, and deployment, as shown below:

Screen Shot 2017-12-03 at 15.12.06.png

Release Process and Versioning in Continuous Delivery 

Basically, I am not a big fan of the Maven release plugin for several reasons. Let’s consider the principles of continuous delivery:

  • “Every build is a potential release.”
  • “The team needs to eliminate manual bottlenecks.”
  • “The team needs to automate wherever possible.”

Current drawbacks and limitations of the Maven release method:

  • Overhead. The maven-release plugin runs three (!) full build and test cycles, manipulates the pom twice, and creates three Git revisions.
  • Not isolated. The plugin can easily get into a mess when someone else commits changes during the release build.
  • Not atomic. If something went wrong in the last step (e.g. during the artifact upload), we are facing an invalid state. We have to clean up the created Git tag, Git revisions, and fix the wrong version in the pom manually.

Let us simplify the versioning process in an efficient way within our continuous delivery model by

  • Checking out the software as it is,
  • Building, testing, and packaging it, 
  • Giving it a version so it can be uniquely identified and tractable (release step),


  • Deploying it to an artifact repository where it can then be picked for the actual roll out on target machines, and
  • Tagging this state in SCM so it can be associated with the matching artifact.

This means:

  • Every artifact is potentially shippable, so there is no need for a dedicated release workflow anymore!
    • The delivery pipeline is significantly simplified and automated.
    • Traceability. It’s obvious which commits are included.

Screen Shot 2017-12-03 at 15.35.41

So how we can implement continuous delivery and a conditional continuous deployment using a Jenkins pipeline? Of course, you can add more stages based into team process, like performance tests; just added until acceptance, as production will be just the same.

We will use a Jenkins pipeline as code as it gives more power to the team to control their delivery process:

  1. When a Git commit is triggered to the development branch, it will trigger the Jenkins pipeline to checkout the code, build it, unit test it, and if all is green, it will trigger the integration test plus Sonar check for your code quality gate.
  2. If all is green, deploy to the development server using the created package from Jenkins work space, or Nexus Snapshots, if you prefer.
  3. Then, if there is a release candidate (which means a merge request to your master branch), it will do the same steps as above, plus creating the release candidate using the release versioning explained above.
  4. Push the released artifact to Nexus and do acceptance deployment and auto acceptance functional testing.
  5. Prompt to production, and if it is approved, it will be deployed into production.
  6. Of course, deployment tasks must be automated if you need continuous deployment, using an automation tools like Ansible, or other options.

Now let us explain how it will be done via Jenkins Pipeline code, as the following:


 You can use it by creating a multi-branch project in Jenkins and marking it to use the Jenkins pipeline as code.


  1. Jenkins pipeline: https://jenkins.io/doc/book/pipeline/
  2. Jenkins file with a sample app for testing the pipeline execution on GitHub: https://github.com/Romeh/spring-boot-sample-app
automation, continous delivery, devops, integration testing, jenkins, jenkins pipeline

Published at DZone with permission of Mahmoud Romeh , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}