Quality & security gates
The checks every change passes before it reaches production.
On every change #
- Code review by a second senior engineer — no self-merges, including the tech lead.
- Automated tests in CI; coverage expectations agreed per project, enforced by the pipeline.
- Static analysis and dependency scanning — known-vulnerable packages block the merge.
- Preview environment built for functional review before sign-off.
On every milestone #
Each milestone closes with a security review appropriate to its risk: authentication and authorization paths re-checked, secrets handling audited, infrastructure diffs reviewed against the baseline. Higher-risk milestones (payments, PHI, public launch) get a deeper pass from our security practice.
Definition of done #
"Done" means deployed, tested, documented, and observable — not "works on my machine." A feature without monitoring is not done; a system without a runbook is not done. This definition is written into milestone acceptance criteria so there is never a debate at sign-off time.
The gates at a glance #
| Gate | Runs | Blocks merge/release when |
|---|---|---|
| Peer code review | Every change | Any unresolved reviewer concern |
| Unit & integration tests | Every change | Any failure — no “flaky, ignore it” culture |
| Static analysis + dependency scan | Every change | Known-vulnerable dependency or critical finding |
| Preview environment review | Every feature | Functional reviewer has not approved |
| Milestone security review | Every milestone | Unmitigated finding above agreed risk threshold |
| Performance budget | Frontends & key APIs | p95 latency or bundle size exceeds budget |
Gates are enforced by the pipeline, not by memory. There is no “just this once” path to production — which is precisely what makes Tuesday-afternoon deploys safe.
Maintained by the delivery team · updated quarterly