Noga Cohen is a Sr. Product Marketing Manager for CA BlazeMeter. She manages the BlazeMeter blog and other content activities. Noga focuses on creating technological content in the fields of performance, load testing and API testing, both independently and by managing writers who are developers. Noga has more than 5 years of experience in a wide scope of writing techniques: hi-tech, business, journalist and academic.

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW!

arrow Please enter a URL with http(s)
Nov 23 2017

Add Jenkins to Your Deployment Processes

One of the top tools to continuously run all of your needed tests while developing, is Jenkins. Jenkins is an open-source continuous integration tool that you can use to automatically run all kinds of tests: load, unit, functional and more. Basically, everything you need for building, testing, and deploying software.


But Jenkins can be used for more than just testing before production. In fact, it’s a valuable tool for ensuring your production is working as expected, all the time. So while you would catch most of your bugs and errors before deploying, some unexpected things might happen afterwards, and it’s important to keep checking. In other words, you can use Jenkins on top of your deployment, as a way to ensure that what you tested before still works, and that no new issues have arisen.


Rather than waiting for full deployment to test, we recommend deciding on your testing strategy according to your deployment strategy. Two of the popular deployment strategies are ‘Blue-Green Deployments’ and ‘Canary Releases’, and Jenkins, or any other CI tool, can be added to the process. Let’s discuss how.


jenkins, continuous testing, deployments


Blue Green Deployments


The idea behind the “Blue Green” deployment strategy is to work with two identical environments, one live (production) and one internal (with the newest version), which are gradually switched when deploying. This way, if errors are found in the new environment, the system can immediately be switched back to the previous, bug-free, environment, until the bugs on the newest version are fixed. Read ”5 Blue-Green Deployment Best Practices for a Smooth Release” for more information.


To implement continuous integration using this strategy, you will need to configure a unique Jenkins workflow for each of the environments, i.e one for ‘Blue’ and one for ‘Green’. Run the relevant tests for the environment in production, let’s say it’s the ‘Blue’ one. At the same time, create and run a Jenkins workflow with tests for the internal environment, the ‘Green’ one. This is your workflow for detecting errors before production.


Don’t use the same workflow for ‘Blue’ and ‘Green’. Rather, make sure that the ‘Green’ test workflow is suitable for the newest version. For example, if your newest release has a new website page that you need to load test, make sure you add that stage to your Apache JMeter™, BlazeMeter, Taurus or other load testing tool’s scenario.


If all tests go as planned for ‘Green’, you are ready to switch your environment. After  environment switching is complete, the ‘Green’ Jenkins workflow will become your main one. But don’t throw away your ‘Blue’ Jenkins workflow just yet! Take the basic tests from it and run them as well on the ‘Green’ environment, to make sure nothing broke when switching environments.


Canary Releases


When deploying using the ‘Canary’ strategy, the newest version is released only to a small number of servers, and consequently to a small number of users, to examine how the new version operates and performs in production. Often, these users are unaware that they are the ‘Canaries’. This way, if errors are found, not all users are affected, and they can be switched back to the previous environment, if needed. If not, deployment can expand to the rest of the users. Another option is to receive feedback from these users and adjust the new version accordingly.


Adding Jenkins to this process is similar to the ‘Blue - Green’ option. Start out with your Jenkins workflow for all users. At the same time, create a Jenkins workflow for our ‘Canary’. Run it before the Canary is deployed, for detecting errors before production. After Canary deployment, keep running it. Now, both Jenkins workflows are run in production. Like before, run a basic test suite from production on the Canary to make sure nothing broke.


If all goes well with the Canary, the second Jenkins workflow will become the main and only testing workflow.


To learn how to configure your Jenkins workflows, in any part of your development or production, check out the following blog posts and webinars:


arrow Please enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!