Today, I’ll be showing you how to add your performance testing with JMeter to a Jenkins Continuous Integration build. Read on and see how it's done.
When a developer is working on a new feature or fixing a defect, he/she needs to ensure that these changes won’t have a negative impact on other software parts which were previously working perfectly. To make the process as efficient as possible, it should be unattended.
For example: if your latest commit inadvertently causes response times to go above an acceptable threshold or SLA, your CI system will automatically raise a 'red flag' and mark the build as 'failed'. This will make it very easy for you to identify the cause (and the responsible person!) behind the problem.
What’s more, it’s much better to start running performance tests in the early software development stages. If you detect a major error in the pre-release phase, it will be much harder to identify and fix the issue.
2. Run Jenkins as java -jar jenkins.war and wait for the "Jenkins is fully up and running" message.
To verify the execution was successful (or to get extra information regarding any problems), check the "Console Output" tab of the project in question.
In the JMeter log file and the .jtl results file, you can find it under the Project’s "Workspace"
The Performance Plugin displays statistics, trends, and can also be used to mark builds as failed based on results.
"Report Files" is the main configuration option here. This is the path where the plugin will scan for JMeter results’ files. The format matches the Ant Fileset include/exclude format, and it’s relative to the Jenkins Workspace for the project.
On the first build with the plugin enabled, you’ll see empty charts for the "Performance Trend".
If you run the build once more and take a look into the "Console Output", you’ll see that the %threads% variable has been changed.
Watch our recorded webcast to learn more about how to you can shift your testing into Continuous Integration and Continuous Delivery Processes.