The summer break is over, we start to creep towards autumn, and we at k6 haven't been resting on our laurels. What happened since the k6 v0.33.0 release? So glad you asked! The below. And then some!
You can find a collection of k6 scripts and build specification for CodeBuild in this tutorial here.
August 7, I joined the Office Hours our Developer Relations team runs on a weekly basis, to talk about how we work at k6. We are growing rapidly, and are a little unconventional in how we organize ourselves, so I thought it would be a good idea to share in more detail how we build and ship software, being a remote-only company.
In this tutorial, we will look into how to integrate performance testing in your development process with Google Cloud Build and k6. k6 is an open-source load testing tool for testing the performance of APIs, microservices, and websites. Developers use k6 to test a system's performance under a particular load to catch performance regressions or errors.
At SLOConf 2021 I talked about how we may use error budgets to add pass/fail criterias to reliability tests we run as part of our CI pipelines. As Site Reliability Engineers, one of our primary goals is to reduce manual labor, or toil, to a minimum while at the same time keeping the systems we manage as reliable and available as possible. To be able to do this in a safe way, it's really important that we're able to easily inspect the state of the system.
One of the more challenging aspects of load testing happens very early on: getting your scripts working. When you run your scripts, you may observe unexpected error status codes (typically in the 4xx-5xx status code range). Other times, you'll run your script and see it receive the expected responses (usually HTTP 200), yet the "thing" your script is meant to create simply doesn't show up anywhere, like on the database or as a record on the site. You start wondering: why on earth is that?
