continous-delivery

Jenkins pipeline for continuous delivery and deployment

mromehLeave a comment

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

Screen Shot 2017-12-03 at 15.12.06.png

What about releasing process and versioning in continuous delivery  :

basically i am not big fan of maven release plugin for some reasons :

Let’s consider the principles of Continuous Delivery.

  • “Every build is a potential release”
  • “Team need to eliminate manual bottlenecks”
  • “Team need to automate wherever possible”

Current drawbacks and limitations of maven release way :

  • Overhead. The maven-release plugin runs 3 (!) full build and test cycles, manipulates the POM 2 times and creates 3 Git revisions.
  • Not isolated. The plugin can easily get in 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.

So let us simplify the versioning process in an efficient way within out continuous delivery model :

  • 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)

  Version=Major.Minor.Patch.GitCommit-Id

  • deploying it to an artifact repository where it can then be picked for actual roll out on target machines
  • tagging this state in SCM so it can be associated with the matching artifact

Which leads to :

  • Every artifact is potentially shippable. So there is no need for a dedicated release workflow anymore!
    • The delivery pipeline is significantly simplified and automated
    • Traceable. 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 Jenkins pipeline , off-course you can add more stages  based into team process like for example performance test, just added till acceptance as production will be just the same :

we will use Jenkins pipeline as a code as it give more power to the team to control they delivery process:

  1. when a Git commit is triggered to development branch , it will trigger 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 green , deploy to 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 , the 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. Then prompt to production and if it is approved it will be deployed into production
  6. Off-course deployment task 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 :

then you can use it by creating multi branch project in Jenkins and mark it to get use Jenkins pipeline as a code

References :

  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
Advertisements

Spring boot integration test with cucumber and Jenkins pipeline

mromehLeave a comment

Here I am sharing how you can integrate cucumber for behavior driven testing with spring boot integration test and how you collect the reports in Jenkins pipeline.

 

In a sample spring boot app generated from my custom spring boot archetype we will show a small integration test suite with cucumber and spring boot.

Steps to follow are :

1- Add cucumber maven dependencies to your spring boot pom.xml

<!-- Cucumber-->
<dependency>
    <groupId>info.cukes</groupId>
    <artifactId>cucumber-java</artifactId>
    <version>${cucumber-version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>info.cukes</groupId>
    <artifactId>cucumber-junit</artifactId>
    <version>${cucumber-version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>info.cukes</groupId>
    <artifactId>cucumber-spring</artifactId>
    <version>${cucumber-version}</version>
    <scope>test</scope>
</dependency>

2- Define cucumber features in your test resources :

Screen Shot 2017-12-03 at 19.00.06

3- How to define the features implementation to be executed with your spring boot app logic :

the feature description :

the feature implementation :

4- How to execute the integration test :

you need to configure the root executor with Cucumber runner as the following:

and the integration test triggering which will be done via spring boot integration test :

5- how to collect the test reports in Jenkins pipeline :

Complete working sample is here :

GitHub: https://github.com/Romeh/spring-boot-sample-app

References :

  1. Cucumber: https://cucumber.io/
  2. Spring boot : https://projects.spring.io/spring-boot/

 

Implement Retry in Unit test

mromehLeave a comment

If you are doing an integration test or sanity testing for real application endpoints in continuous delivery process where you hot deploy the application and and you want to trigger some checkups and sanity testing part of your delivery pipeline , how you can add retry logic with delay to unit testing and to your integration test ?

Sample app that include a working demo for it at the following :

https://github.com/Romeh/spring-boot-sample-app

So I will through about how you can do it :

  • We will create annotation to mark the test cases needed to be retried :

  • We will create the implementation using JUnit rules option :

  • sample of how you can use it :

Then when you execute the test and your endpoint is not reachable right away , it will retry again based into your retry configuration .