Load Impact integrates nicely with Jenkins, a leading continuous delivery and integration automation platform. Using our robust and extensible APIs you can integrate Load Impact’s world-leading performance testing platform into your automated Jenkins pipeline build and test process.
Building a continuous load test might seem intimidating, but it’s not. You may think continuous load tests entail extensive integration, finicky server setup, detailed custom scripts, and a lot of annoyance mixed with caffeine and long hours.
(Warning to readers: this article is long and rambling, like most articles by the same author)
Once upon a time, I wrote a very simple command-line load testing tool in C. I called it "myload", partly because it was written by, well...myself, and partly as an allusion to MySQL (this was back in the days when MySQL ruled and I had yet to start using PostgreSQL).
Most developers are extremely familiar with automated testing as part of their CI/CD pipelines. Continuous improvement and continuous delivery integrate unit testing as a matter of course.
But there’s another type of testing you *should* be doing, but most developers aren’t. Since we’re load testing experts, we’re sure you’ve already guessed our recommendation: add load testing to your automation pipelines.
Continuously performance testing websites, apps and infrastructure throughout the development cycle is a growing practice in the software industry.
We’re helping lead that charge by making Load Impact the most DevOps- and continuous delivery-friendly performance testing solution on the market.
We’ve talked to thousands of software developers around the world (we’ve been around for 6+ years now) and most people who decide to integrate Load Impact into their continuous integration environment have a few different reasons, but they all lead back to the same two principles: Saving time, and saving money.
At Load Impact we believe in goal oriented and automated load testing. That's why we have built k6 to work smoothly in such environments, integrating nicely with tools like CircleCI, Jenkins and TeamCity. Now we can offer even more integrations such as AWS Codebuild, bash (*nix /MacOS) and PowerShell (Windows)
The secrets to an effective DevOps team are communication and collaboration. This is especially true in load testing.
The #1 best practice we recommend with your regular load testing is to set pass/fail triggers with your automated build processes. (We’ve talked about that elsewhere.) As part of those triggers, failure notifications should be set up in a shared communications channel.
For the most accurate load test, best practices (and common sense) dictate that your testing environment be as close to real production and user behavior as possible. We get it, though! Best practices don’t necessarily reflect the challenge and rush of a real development pipeline. For example, if you’re like us, you likely have a much larger amount of data in your production environment than in your testing and staging environment. A detailed, extremely realistic testing database is nice, but perhaps not necessary. Let us explain.