As some may already know, Load Impact recently let loose upon the world yet another load testing tool - k6
As we’re big believers in dogfooding we’ve used our open source load testing tool, k6, to set up load testing automation with CircleCI. This is how we did it, and some tips and tricks to make your load testing automation easier. Let’s go!
Tl;dr — We're hosting a DevOps Stockholm meetup at our HQ in Stockholm. The headline of the event is "How to load test, the developer way" by Robin Gustafsson.
This webinar not only shows you how to automate load testing in your CI pipeline, but you’ll also learn how Julien applies Microsoft’s best practices to the DevOps and “continuous” mindset while embracing the world of open source software.
Continuous load testing throughout the software development process improves your understanding of your website, application and infrastructure performance.
Developers around the world are discovering that load testing isn’t just a one-off project or something you wait until the last minute to do.
Integrating load testing into your DevOps and Continuous Integration lifecycle helps you achieve a few things.
- Load testing is yet another task you can automate — and we know that’s a good thing
- Understand the performance impact of each code commit
- Plot your app or website’s performance trend over time
Performance testing is often mistaken for performance tuning. The two are related, but they are certainly not the same thing. To see what these differences are, let’s look at a quick analogy.
Most governments mandate that you bring your vehicles to the workshop for an inspection once a year. This is to ensure that your car meets the minimum safety standards that have been set to ensure it is safe for road use.
A website performance test can be likened to a yearly inspection — It ensures that your website isn’t performing terribly and should perform reasonably well under most circumstances.
In part one of this series, we started defining the problem we are solving. Essentially, we are trying to leverage Docker and DevOps tools to ensure our decentralized team can release faster and with less centralized synchronisation. Before we dive into software choices, we have to talk about the elephant in the room.
Tl;dr — More Load Impact customers than ever are continuously running load tests. In response, we’ve just shipped our “Performance Thresholds” feature. Now, engineers set Pass/Fail metrics for their scheduled tests in order to hone in on the data that’s most important to them. Here’s how we think that helps you:
- The binary status of Pass/Fail metrics is great for automated Continuous Integration flows
- Set thresholds for VU load time, page load time or any of your custom metrics
- Know right away if a test passed or failed your expectations
- Configure tests to abort when a metric fails and avoid completely crashing your application
Tl;dr — Load Impact is growing, and one of the challenges with growth is making sure your infrastructure and development cycle mature with that success. This is Part 1 of our series, “The Road to Microservices.” Here’s what we’ll cover:
- Why we decided to make the change to a microservice-oriented approach
- We’re switching to Docker! (Isn’t everyone, at this point?)
- What we expect to get out of these changes
One of our favorite aspects of working in performance and load testing is that we have the privilege of working with great companies across every industry.
Every so often we make contact with a user who’s not only building great products with great success, but someone who really understands the value of DevOps and Continuous Testing.