Project: release evidence and capacity

Last updated: 5 Oct 20268 min read

project

Prepare a release gate for the case-review service. A reviewer searches, opens, adds a note, and resolves a case. Keep pure transition rules under fast unit checks. Use a database test to show that status and note are atomic. Send raw JSON through the authenticated API to verify the contract. In a browser journey, check visible errors, focus, names, and a stable narrow layout. Use deferred responses to force stale request outcomes without sleeps. Then run a nonprivate mixed workload across search, detail, and note writes. State tail-latency and error thresholds before running; a fast mean from one cached route is not enough.

Build contract

Map each failure to a boundary that can observe it: pure rule, transaction, API, browser task, or loaded service.
Control response order and rejection with deferred test doubles, then compare their payload contract with a real endpoint.
Run a mixed workload with offered and completed traffic, per-route tail latency, error rate, and saturation measurements.

Implementation checkpoint

function releaseBudget(report) {
  return report.searchP95Ms <= 420 && report.writeErrorRate < 0.01 &&
    report.completedPerSecond >= 47;
}
console.log(releaseBudget({ searchP95Ms: 390, writeErrorRate: 0.004, completedPerSecond: 49 }));
// Output: true

Cost and boundaries

The pure checks are cheap; real database, browser, and load checks take longer and need stable fixtures. Keep the critical gate small enough to run every change and reserve extended capacity studies for a controlled environment. Screenshot artifacts need deliberate review after design changes. A load generator can also become the bottleneck, so compare offered with completed traffic and inspect its own resource use. Record the environment and data shape beside every capacity claim, including differences from production.

Failure drill

Inject a note-write failure after a status update and confirm the transaction rolls back. Make case 62 return before case 47 and then reject the old request; neither old completion should alter the current route. Break the form label and narrow layout to prove semantic and visual checks fail for different reasons. Increase traffic until the connection pool queues work. A release should fail when the predeclared tail or error budget is crossed, even if average latency and total successful request count look acceptable.

Acceptance checks

A failed note write leaves the case open with no partial resolution.
Both response orders and an obsolete error leave the current route state intact.
Keyboard and visual checks catch field-feedback and narrow-layout failures.
A sustained mixed load reports offered/completed rate, per-operation p95, errors, and saturation against fixed thresholds.

Common Mistakes

Using unit tests as proof of database atomicity.
Adding sleeps instead of deterministic response controls.
Accepting screenshot updates without inspecting the changed task.
Testing only mean latency from a cached route.

web-tech

web-development