В предыдущей части мы разобрали автоматизацию обнаружения регрессии андроид приложении на уровне pull request и выяснили какие имеет недостатки.

Для напоминания, единственный недостаток - сборка development билда на каждый commit, что нагружает наш CI, так как нам не всегда нужно запрашивать development apk для сравнения в зависимости от измененных файлов.

Решение

Откажемся от сборки apk в development ветке на каждый commit

В pull request наш flow останется почти таким же, за исключением пару шагов:

1. Собираем app bundle ./gradlew bundleRelease

2. Собираем конкретный apk, с единымdevice-spec.json

3. Так как у нас не будет готовых apk в development ветке, нам надо собрать его из pull request. Для этого получаем head(соединяющий) commit веток development и feature. Делаем checkout этого коммита:

head_commit=$(git merge-base "development" "feature/task1")
git checkout $head_commit

4. Собираем релизный app bundle из этого head коммита ./gradlew bundleRelease

5. Собираем конкретный apk с единым device-spec.json

Дальше все то же самое, что и в предыдущем флоу. И так как сборка apk текущего pull request коммита и сборка apk c head commit, не связаны между собой, можно распараллелить их, что позволит сохранить время.

6. Сравниваем наши apk, используя diffuse tool

7. Результат сравнения постим как комментарий в pull request

8. Блокируем/разблокируем Pull request в зависимости от обнаружения регрессии

Итог

Наш финальный flow будет выглядеть вот так:

Теперь мы собираем релизные apk только когда нам нужно проверять размер приложения(в зависимости от измененных файлов). Что позволяет не нагружать CI, как показывает практика, проверка размера приложения требуется в ~30% открытых пулл реквестов.

В результате, мы все также имеем:

• Автоматизированное обнаружение регрессии размера приложения на уровне pull request

• Полная видимость изменения размера приложения в процессе разработки