CI에서의 추세 분석 및 기준선 설정

Pass/fail gates catch obvious breakage, but slow drift over weeks is invisible to a single run. Baselining compares each build against historical performance to catch creeping regressions.

A baseline is a stored reference result, usually the metrics from a known-good build. New runs are measured against it. Common baselines are the previous release or a rolling average of recent runs.

To compare across builds, tag each run with a unique identifier such as the commit SHA or build number. This lets the backend separate and chart each run.

Persist results in a time-series database (InfluxDB, Prometheus) or a results store. Without persistence there is no history to trend against.

Decide how much regression is tolerable, for example p95 may not exceed the baseline by more than 10%. Encode this as a comparison step in the pipeline.

A small script can read the new p95 from the k6 JSON summary and fail the build if it exceeds the allowed drift.

Instead of one fixed reference, a rolling baseline averages the last N runs. This adapts to gradual, intentional changes while still flagging sudden regressions.

A Grafana panel of p95 over build numbers makes drift obvious to the whole team. A slowly rising line is a warning even when every individual build passed its gate.

Run performance tests on consistent, isolated infrastructure. Comparing against a baseline collected on noisy shared hardware produces false regressions and erodes trust.

When a release intentionally changes performance, promote its result to the new baseline. Automate this so the reference stays current without manual edits.

Mark deploys and config changes on your trend charts. An annotation at the exact build where p95 jumped turns a mysterious line into an obvious culprit.

Test your trend-analysis knowledge.

You learned to trend performance in CI.

• Tag and persist every run for history.
• Define acceptable drift and compare new runs to a baseline.
• Use rolling baselines and clean infrastructure to avoid noise.