Continuous Performance Testing in DevOps
summary
Claim: traditional performance testing is dead for DevOps; instead build a continuum of performance data by adding small, frequent checks at commit (use unit-level testing with JMH for Java), integration (component API calls, mocked deps), acceptance (browser timing APIs), and production (synthetic transactions plus monitoring), store metrics in a time-series DB and trend them. A 2019 report shows only ~28% of elite teams have automated perf tests. Start with one component, measure regressions to the offending commit, and iterate—this yields earlier, actionable fixes and lower remediation cost.
AI-written summary · about
chapters (18)
- 0:00Continuous performance testing intro
- 1:08Why traditional testing fails
- 3:14Risks of late detection
- 4:59What is continuous testing
- 6:27Obstacles to automation
- 8:33Early performance requirements
- 11:24Accountability for performance
- 13:50From centralized to team ownership
- 14:33Performance at every stage
- 15:57JMH unit testing
- 18:02Integration stage testing
- 20:53Acceptance evaluation
- 22:17Tooling and trends pipeline
- 23:20Start small scale up
- 26:36Production performance testing
- 29:45Mitigating production risks
- 31:08Key takeaways
- 32:13Answering audience questions
related talks
44mContinuous Performance Testing in DevOps
41mPerformance Engineering in the Age of DevOps and Agile
33mPerformance Testing in Agile and DevOps
40mWhy component level performance testing should always be part of CD and CI
29mProgressive Testing to Meet the Performance Imperative
32mBetter Continuous Testing in DevOps
44mStrategy for Acing Continuous Testing in DevOps
37mThe Evolution of Performance Testing to Performance TestOps