Gradle Enterprise & AAB Tests

В большой команде, Gradle Enterprise является практически незаменимым инструментом.

Огромное количество аналитических утилит, remote build cache, predictive test selection позволяют держать build & verification time локально и на CI в тонусе.

Практически всегда это дешевле, чем разрабатывать и поддерживать свои инструменты.

Ребята из Slack первое время даже пробовали сделать свой аналог, над которым работал инженер на full-time, которому за квартал заплатили больше, чем стоимость Gradle Enterprise за год

Недавно, мне пришлось поработать с расширенными параметрами в build-scans, с помощью которых можно делать эксперименты.

Где могут пригодиться AAB тесты?

С точки зрения мобильной платформенной команды, мы используем их для выявления лучшей конфигурации. Перед тем, как раскатывать изменения на 100% разработчиков, важно быть уверенным, что мы делаем лучше.
Будь то выбор GC, максимальный размер Heap под Gradle/Kotlin Daemon, или другие изменения, которые могут сократить время верификации локально и на PR-ах.

Но так же, это может помочь в исправлении возникших проблем.

Например, недавно мы обнаружили, что часть верификационных билдов на CI падает с Out of memory.

Во всех случаях, это происходило на этапе lint или unit-tests.

Как обычно, проблема возникла «ни с того ни с сего» :)

Недавно, DevOps-команда увеличила нам количество ядер в нашем пуле билд-агентов, что, предположительно, являлось причиной.

Как правило, количество org.gradle.workers.max эквивалентно количеству ядер. У нас так же включено параллельное выполнение, соответственно, количество параллельной работы увеличилось, при том же объёме оперативной памяти.

Но это гипотеза, которую нужно подтвердить, перед тем как исправлять проблему.

Я решил сделать AAB тест, чтобы точно быть уверенным в причине.

Как это сделать?

Концептуально, нужно на каждую верификацию на CI запускать конфигурацию, которая отличается от предыдущей и сохранять результат выполнения с идентификатором эксперимента.

На практике, это легче, чем кажется на первый взгляд. Мы можем оперировать номером сборки получать остаток отделения от количества экспериментов, на основе которого можем выбирать нужные gradle.properties

Какой результат

По каждому эксперименту накопилось по ~1500 билдов.
Gradle Enterprise автоматически сохраняет сканы после выполнения тасок и позволяет агрегировать их результат по тагам или параметрам.
Как и ожидалось, по CLUMSY_MOOSE больше всего потерь потерь.

Как быть без Gradle Enterprise?

Если вопрос в анализе производительности и подборе лучшей конфигурации, можно использовать gradle-profiler. Но полноценный AAB тест на живых людях сделать не получится. В любом случае, придётся запускать профайлер снова и снова и анализировать результаты вручную. Это так же поддаётся автоматизации, однако, она занимает существенное время.

Учтите, что Gradle Enterprise не является полноценной заменой gradle-profiler.
Если вы хотите предотвратить мёрж изменений, которые потенциально могут сделать вашу верификацию медленнее, то любое обновление Kotlin, Gradle, AGP и кор библиотек с annotations processing важно измерять, перед мёржем в development.

В одном из следующих постов, я расскажу про уменьшение времени build time.

___________________________________
@invalidate_cache

Немного про Manifest & Android 12 (July 9, 2022)