Skip to main content

Boardroom Answers · Technology & Platform · Operational Excellence

Walk me through your CI/CD pipeline, step by step, as it actually exists — not the aspiration.?

The question a VP Engineering / Head of Platform asks.

The short answer

Lint, strict types generated from the real schema, an AI regression gate with zero model calls, 3,577 tests, dependency audit, browser-level security smoke test — then auto-deploy; the pipeline file is the proof.

The full executive answer

I can walk you through the actual pipeline file, because it is checked into the repository. On every push and pull request, one job runs in strict sequence: dependencies installed with a locked, reproducible install; lint — including accessibility rules that block on error; a full strict type-check, where the database schema types are generated from the migrations themselves so every query is compile-time checked against the real schema; then the eval gate — our AI regression harness, which runs golden fixtures and mutations through every registered AI output schema with zero live model calls, so a prompt or schema change that would break AI behaviour fails the build; then all 3,577 tests across 344 suites; then a dependency vulnerability audit at high severity.

Two details a VP Eng will appreciate: concurrency control — a newer push automatically cancels the superseded run, so the pipeline never queues stale work; and a second post-merge job on the main branch that does a full production build and drives a real browser with Playwright to prove the protected routes actually redirect unauthenticated visitors — an end-to-end security smoke test, deliberately run without any real secrets so CI can never leak what it never had. Green main auto-deploys to production on Vercel; rollback is redeploying the previous immutable build.

Honest maturity assessment against the DORA model: deployment automation, trunk-based development, test automation, shift-left security — present and real. Present gaps: the dependency audit is currently advisory rather than build-blocking, and there is no mandatory second-reviewer gate yet at current team size — both are deliberate pre-launch positions with hardening scheduled as the team grows.

Grounded in: DORA capabilities model (continuous delivery, trunk-based development); trunk-based release engineering

Want this answered live, on your data?