Why component level performance testing should always be part of CD and CI
summary
Argument: put component-level performance tests into CI/CD so regressions are visible before integration. Capture execution time, API response time, CPU/memory footprint per build and trend them in dashboards (Grafana/Kibana, SSRS or similar). Reuse functional automation (Selenium), JMeter or existing APMs (New Relic, perfmon) and alert on surprises — e.g. build 1 20ms → build 10 300ms or a component that must process 1,000 orders ≤30s. Pilot microservice work proves it finds and fixes defects early.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:24Who does performance testing
- 5:05Performance testing in dev
- 8:26Components
- 14:54Microservers
- 15:15Delivery Services
- 15:47Early Testing
- 17:24Benchmarks
- 18:44Automation
- 19:29Monitoring tools
- 19:59Environments
- 21:04Test scenarios
- 21:41Visualisation
- 23:41How to make the visual
- 25:40Obstacles
- 27:02Hybrid approach
- 28:18Nonfunctional testing
- 30:17Performance testing
- 35:15Questions
- 37:27Potential for conflict
related talks
41mContinuous Performance Testing in DevOps
44mContinuous Performance Testing in DevOps
41mPerformance Engineering in the Age of DevOps and Agile
29mProgressive Testing to Meet the Performance Imperative
33mPerformance Testing in Agile and DevOps
39mCreating & Scaling Meaningful Performance Tests in CI
40mAutomated Performance Testing In Preproduction
53mEarly Performance Testing: Finding News You Can Use