Use cases / Platform teams and architects
Seeing sixty repositories as one system
Which service calls which, what they share, and where a vendor is used by eleven of them.
The problem
Nobody has the whole picture. The diagram on the wiki was drawn two reorganisations ago, and the question “what talks to the orders database” takes a week of asking around.
What visualdiff does
- Reviewed repositories are drawn together: the calls between them, the databases, queues and outside vendors they share, grouped by system, team or language.
- A lens per reader: a developer sees imports and shared code, DevOps sees what is deployed where, an architect sees the boundaries that are crossed.
- Every view exports as Mermaid, DOT, CSV, Markdown, SVG or PNG, so the wiki page and the architecture decision record are drawn from the code, not from memory.
- A repository nobody uses any more is archived: out of the drawing and its exports, called out apart, its reviews kept.
The estate is built from stored reviews, and a push to a reviewed branch reviews it again, so the diagram is at most one push behind the code.
Related
- Reviewing pull requests written by agentsAgents open pull requests faster than anyone can read them. Read the 10% that decides whether it is safe.
- Large refactors that hide a behaviour changeA refactor is supposed to change nothing. Find the one line that does.
- Stopping hallucinated dependenciesSlopsquatting: attackers register the package names models invent. Catch them at review.
- Seeing which running systems a change reachesThe diff says rds.tf. The map says orders-db, the API in front of it, and the queue behind it.