Load testing is a common and typically important stage in the CI process for organizations of all sizes. We will help developers shift left by making performance decisions earlier in the development process by providing a measure of how software responds under load as changes are introduced.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
This page is maintained by the Product Manager for Testing, James Heimbuck (E-mail)
Up next is the Integrated Load Testing MVC (gitlab-org#952). This epic brings performance testing as a category to minimal maturity and provide a baseline experience on which we can learn more about the problems users face in load testing their software.
This category is currently at the "Planned" maturity level, and our next maturity target is "Minimal" (see our definitions of maturity levels). Key deliverables to achieve this are:
Azure DevOps offers in-product load testing. This consists of different types of tests including:
For URL type tests, the output contains information about the average response time, user load, requests per second, failed requests and errors (if any).
While, just as one could orchestrate any number of performance testing tools with GitLab CI today, Travis or CircleCI could be used to orchestrate performance testing tools, it does not have any built-in capabilities around this.
The most popular issue in this category is for the integration with k6 (gitlb#10683).
The top Vision item is gitlab-ee#10681 which will add Integrated Load Testing as an Auto DevOps step. This will mean that what we have defined as minimal for this category will now be added to every Auto DevOps pipeline.