Дашборд, которому можно верить: очередной рассказ об ускорении сборок

tc-mono — монорепо на ~1,9 млн строк кода (Kotlin, Swift, Java): ~416 Gradle-модулей и 9 composite-сборок, растущие на ~28 тысяч строк в неделю.

Данных о том, что реально происходит на сборках у сотни разработчиков, долго не было — а значит, не было и системных попыток их ускорять. За несколько месяцев мы построили конвейер метрик — Gradle-плагин → ClickHouse → Grafana — и первые же графики показали неожиданную картину. Правда, сначала дашбордам нельзя было верить: метрики ломал то один разработчик с зацикленной сборкой, то дубли данных, завышавшие p95 вдвое, то сама ось времени.

Когда графики научились говорить правду, выяснилось: Configuration Cache у части разработчиков просто не включался — и причина оказалась не в коде репозитория, а в том, как именно они открывали проект. Самое дорогое время уходило не туда, куда мы думали: не на компиляцию, а на подготовительный шаг, который до этого никто отдельно не мерил. А стабильно низкое переиспользование кеша (12–19% почти у всех) оказалось не одной проблемой, а суммой десятка независимых причин. Расскажу, как строился сам инструмент, как мы учились читать его показания и как каждая находка меняла то, что мы чинили дальше. Отдельно — что не сработало и сколько всё это сэкономило компании.