How would you roll out a new analyser across many repositories without stalling delivery?

### The failure this question is really about Nearly every organisation that has adopted static analysis badly did the same thing: turned on a large ruleset everywhere, made it blocking on day one, and discovered on the following morning that half the fleet could not merge. The recovery is worse than the mistake, because the fastest way out is a blanket suppression that nobody ever removes. So the interview question is not "which analyser" — it is whether you treat adoption as a schedule with measurements and an owner, or as a switch. ### Sequence the placements before you sequence the rules Findings should be visible before they are blocking, and visible in the place where they are cheap to fix. A workable order: 1. **Editor first.** Ship the configuration and the pinned analyser version, and make the editor integration a documented, one-command setup. People start seeing findings on the code they are writing, at zero cost to anyone's merge. 2. **Pipeline, non-blocking.** The analysis runs on every change and publishes its findings — annotated on the change and counted in a trend — but the step cannot fail the build. This is where you learn the real finding rate, which is never what the pilot suggested. 3. **Blocking on changed code.** Enforce for the code the change introduces. This bounds the work to what the author is already touching and makes the gate arrive with a fix that is in scope. 4. **Widening.** Only then, if it is worth it, extend the blocking scope, on a rule-by-rule basis rather than wholesale. ### Choose rules by signal, not by count The temptation is to enable everything the analyser offers and prune later. Do the reverse: start with a small set of rules that are high-confidence, cheap to fix, and ideally auto-fixable, and measure their signal-to-noise on a sample of real findings before enabling them for anyone. A rule whose findings are correct 96 percent of the time and fixable in a minute earns a gate. A rule that produces plausible-looking findings a reviewer has to argue about does not — not because it is wrong, but because the cost of the argument is charged to every change forever. Repeated exception requests are your best data. If four teams ask to disable the same rule, that is evidence about the rule, not about the teams; sample its findings and be willing to downgrade or drop it. A ruleset that never loses a rule is not being governed. ### The warn phase needs an end date A non-blocking phase with no announced enforcement date decays into permanent noise: the findings are published, nobody is obliged to act, and within a month the report is not read. Publish the date when you start the phase, and publish the criteria you will check before it — the rate of new findings per change trending down, the share of changes introducing a new finding under an agreed threshold, autofix available where it can be, and no unresolved dispute about a rule. If the criteria are not met, move the date and say why; do not let the phase run on quietly. ### Ownership, exceptions and blast radius Decide who owns the shared configuration and how a team changes it. A central config with no route to an exception guarantees local forks or bypassed gates; an exception path with no record guarantees that nobody can ever tell what is enforced. Give exceptions an owner, a reason and an expiry, and make the set of active exceptions visible. Be equally deliberate about the enforcement mechanics you *do not* own: how the pipeline expresses a required check and who may override it is somebody else's design, and your rollout should ride on the existing mechanism rather than inventing a parallel one. ### Budget the time you are adding Analysis is not free. A 27-minute pipeline that becomes 34 minutes has spent seven minutes of every engineer's day for the rest of the project's life. Run the analysis in parallel with tests rather than in series; scope the blocking run to the change; cache results keyed on content, configuration and analyser version; and put whole-repository scans on a schedule instead of on the critical path. ### The organisational tradeoff to name out loud Enforcing a large ruleset across a whole codebase at once also produces a wave of mechanical edits that collide with in-flight work, churn review diffs and obscure authorship history. Staging by placement and by rule spreads that cost. The opposite failure is real too: an adoption that never reaches enforcement is a report nobody acts on, and it is worse than not starting, because it consumed budget and taught the organisation that quality programmes fizzle. Name the date, hit it, and be ready to trade rule count for credibility.