My Experience with Jenkins for Performance Testing

In the early days of my 45-plus year career, I got very familiar with Job management tools like JCL and JES 2 in the mainframe environment. It was essential to become knowledgeable about these command languages to implement batch jobs. But moving onto the PC environment I had to relearn job management.

On the PC the terms job scheduler and task scheduler came into existence. Microsoft’s task scheduler was the first automation tool I became familiar with and utilized. The Task Scheduler is a tool that allows creation and running of virtually any task automatically. Now there are many task and job schedulers available to manage this type of automation depending on the operating system and its release. Jenkins is one of these tools. It runs through a web port and is an open-source automation server which enables users to reliably build, test, and deploy their software.

The concept it supports is wider than that. It provides features that support creating job requests that can run manually, based on a trigger, or at an appointed time. It can also be scheduled for repeated execution. The primary purpose of its capabilities is to conduct preparatory actions before testing an application release, and then deploying the release into a target environment, if no errors are found. The concept has been in use for several years.

Developers have been the primary users. Then QA engineers started tapping into the process where functional tests are integrated into the test flow to confirm critical functions pass the test before moving on to application deployment. Recently QA engineers have started designing performance test processes as part of the “shift-left” idea. Shift-left is the practice of moving testing, quality, and performance evaluation processes early into the software development lifecycle.

My reason for this article is to discuss the idea of integrating performance testing in a daily Jenkins test flow. Having performance test tasks built into a daily build, test, and deployment process is beneficial. The benefits with this approach are:

  • Reduction of performance bottlenecks early in the cycle
  • better performance of the application code early in the cycle
  • more time allowed for developer improvements to code performance issues
  • ensuring performance objectives are met as early as possible

The objectives of including performance testing in with functional testing is to conduct comparative analysis on application request response time, page load time, report rendering time, and data volume impacts.

Jenkins is the preferred tool these days for making shift-left performance activities happen. It is not the only continuous integration and continuous deployment (CI/CD) tool available, but it is certainly a good solution. I want to include in this discussion the activities involved with preparing to use Jenkins and how test job scheduling, monitoring, and results analysis are done to form a CI/CD pipeline.

The idea of a pipeline in software is to arrange software execution so that the output of each is the input of the next. If you can automate the executions to trigger a process, check its results, and trigger the next process; you have a pipeline. That pipeline we call CI/CD when the processes start with building or changing code and then ends with deploying the code for subsequent execution. Code building and deploying is the simplest form of continuous improvement, integration, and delivery or deployment as in the diagram below.

                   CI/CD Pipeline Workflow

The three processes input something and produce a product. It may not be obvious to everyone what these “Code” actions do for getting to the final stage of the software product. Let me expand on the idea. Code improvement is a process that involves developing, reviewing, editing, storing, and retrieving. It can also require the need to manage track changes in the form of versions in case older changes need recovery. This may be an action taken to return the code to the last time the source had no errors or was considered stable.

A tool that provides source change management (SCM) capabilities is what is needed to fulfill the Improve Code process. A common solution is the use of GitHub with Git commands. These commands are used to manage tracking and movement of source code between local and remote repositories.

Code integration and deployment processes are engaged each time code modifications are implemented. Some code must be compiled to become an executable, and some code is packaged. There may be scripts that must be executed to run tests, while input files are processed for configuration purposes or data population.

The final product is released for use internally to a company or externally for business purposes. These processes can include one or more tools to complete necessary actions that generate a result or product. The result or product becomes input to a subsequent process until product release.

JENKINS PIPELINES

Pipelines are jobs in Jenkins that are enabled by the Pipeline plugin and built with simple text scripts that use a Pipeline based on the Groovy programming language. There are also plugins that are available to support the use of certain performance test products. For instance, here are some performance test products that use plugins to interface with Jenkins:

Jenkins is a tool that enables trigger-based, scheduled-based, or immediate execution of a series of tasks. It forms projects involving steps and post-build actions and is known as a repeatable build job. It limits the types of actions you can perform in a build step or post-build action. Jenkins is comprised of several types of projects. The most common are known as freestyle project, Maven, and Pipeline. Plugins are associated to these projects to assist with the success of each project type.

The diagram below is intended to identify a Jenkins Pipeline workflow. Four major steps are included: Build, Configure, Test, and Deploy. The Build steps are focused on the application execution components and application data environment. Here programs are compiled if necessary. And databases are populated with necessary data to create the necessary test volume. The Configure steps might include application and test settings to control the execution environment. The Test steps should include test processes that conduct quality assurance for the target application. If the results are positive, then the Deployment steps execute tasks that release the updated application software to one or more target environments.

Jenkins Pipeline Workflow

CI/CD REFERENCES

I plan to create a video on this subject. The video should help with product installations, project setup and execution so that you have a start-up guide.

Here are some references that you should find helpful: