Code Review: from violations to rule ownership

Database migrations carry real risk. A poorly written script can cause data loss, downtime or irreversible schema changes in production. Code Review is a Flyway Desktop feature that analyses migration scripts against a configurable ruleset and surfaces violations before a migration runs. It gives DBAs and developers a systematic way to catch problems early, rather than relying on manual review or discovering issues after the fact.

The feature had two distinct design challenges that needed solving in sequence: how should violations be surfaced clearly and actionably, and how should people configure and manage the rules that govern them? This case study covers both.

I attended SQLBits 2026 as field research and had seven practitioner conversations with DBAs, platform engineers and community ambassadors. Code Review as a problem space was validated unprompted. People raised concerns about script quality, permissions, audit trails, and AI-generated migrations reaching production without human review. Several described painful manual review processes that Flyway’s Code Review could replace.

That confirmed the feature was worth investing in, and it sharpened the framing: Code Review needed to feel like a professional DBA tool, not a linting afterthought.

The core problem was presentation. When Flyway Desktop detects issues in a migration script, how do you show them in a way that’s fast to scan, clearly categorised and easy to act on, without obscuring the code itself? Two categories needed visual distinction: Migration Warnings (risks to whether a migration succeeds) and Code Quality Issues (style and pattern violations). The violations panel lists both, with severity badges, line references, inline suppression controls, and a “learn more” path that explains each rule in plain language rather than restating its name.

Before designing the second leg in full, I ran hall tests with three internal participants using early rule-configuration screens. The sessions surfaced three clear findings that directly shaped the final design.

The rule configuration design needed to let people do three distinct things in one place: understand what rules exist, manage which apply to their project, and get those rules into their CI/CD pipeline. The final design handles each clearly without conflating them.

Alongside rule configuration, I designed an in-app feedback mechanism that appears at contextually relevant moments across four product surfaces, including the Code Review violations panel. It uses progressive disclosure: a lightweight star rating appears first, and only expands into a categorised follow-up question if the person engages. The initial ask stays non-intrusive while still collecting structured signal when people choose to give it.

Two follow-up paths were designed for the Code Review context: one for positive ratings, asking what made it helpful, and one for negative ratings, asking what could be better. Each offers pre-filled categories drawn from likely failure modes, with an open “Other” option. The point was to give the team direct signal from active users at the point of use, rather than relying on support tickets or NPS to understand how the feature was landing.

The violations experience shipped and was presented at a design share slot. I took the rule-configuration work through hall testing to final designs, largely independently, running design reviews with the engineers building it so design gaps surfaced early rather than after the fact.

I haven’t put an adoption number on this page because there isn’t one I can stand behind yet. What this project shows is the shape of the work: two audiences (DBAs and developers), rule ownership and governance, two connected surfaces designed in sequence, and research at each stage that changed the design.