|
| 1 | +--- |
| 2 | +title: Performance Bot ADR |
| 3 | +description: ADR proposal for the performance bot integration |
| 4 | +--- |
| 5 | + |
| 6 | +# Performance Bot Integration |
| 7 | + |
| 8 | +## Authors |
| 9 | + |
| 10 | +- Andrea Lamparelli |
| 11 | + |
| 12 | +## Motivation |
| 13 | + |
| 14 | +This proposal aims to empower development teams by tightly integrating performance testing into their daily workflow. |
| 15 | +The current model, where performance validation occurs late in the release cycle, creates a disconnect and often results |
| 16 | +in unforeseen issues and urgent fixes. By enabling repositories to directly trigger performance tests from commits |
| 17 | +and/or pull requests, we are bringing performance analysis closer to the developer. This 'shift-left' approach will |
| 18 | +make it significantly easier and faster to pinpoint the exact changes that introduce performance regressions, |
| 19 | +streamlining the development process and preventing performance-related problems from ever reaching production. |
| 20 | + |
| 21 | +## High-Level Architecture |
| 22 | + |
| 23 | +To achieve this integration, we propose to develop a modular and extensible infrastructure that serves as an agnostic |
| 24 | +middleware. This system will function as a central communication bridge between source code repositories and various |
| 25 | +performance testing environments. |
| 26 | + |
| 27 | +The core of this middleware will be a standardized API that decouples the repositories from the specific lab |
| 28 | +implementations. |
| 29 | + |
| 30 | +Its primary responsibilities will include: |
| 31 | + |
| 32 | +1. Receiving webhook events from repositories. |
| 33 | +2. Translating these events into API calls to trigger the appropriate test pipelines in a configured performance lab. |
| 34 | +3. Integrates with external datastore to monitor performance test results. |
| 35 | +4. Retrieving and formatting the performance results to be reported back to the original pull request. |
| 36 | +5. This pluggable architecture ensures we can easily add support for new labs or source control systems by simply |
| 37 | +developing a new connector, without altering the core logic. |
| 38 | + |
| 39 | + |
| 40 | + |
| 41 | +## Goals |
| 42 | + |
| 43 | +TBD |
| 44 | + |
| 45 | +## Architecture |
| 46 | + |
| 47 | +TBD architecture in the first implementation (coupled with GitHub, Jenkins and Horreum) |
| 48 | + |
| 49 | +### Integration with repositories |
| 50 | + |
| 51 | +TBD webhook, GitHub app configuration as well as perf-bot specific config |
| 52 | + |
| 53 | +### Multi tenancy |
| 54 | + |
| 55 | +TBD security and isolation (one perf-bot instance per repository to integrate) |
| 56 | + |
| 57 | +## Alternatives |
| 58 | + |
| 59 | +TBD |
0 commit comments