В предыдущей части мы разобрали автоматизацию обнаружения регрессии андроид приложении на уровне pull request и выяснили какие имеет недостатки.
Для напоминания, единственный недостаток - сборка development билда на каждый commit, что нагружает наш CI, так как нам не всегда нужно запрашивать development apk для сравнения в зависимости от измененных файлов.
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/f5f/8d0/bbc/f5f8d0bbc3f2a2c5ebc506202039f007.png)
Решение
Откажемся от сборки apk в development ветке на каждый commit
![](https://habrastorage.org/getpro/habr/upload_files/6dc/633/700/6dc63370036ab89c38b2917b5169fdc4.png)
В 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 будет выглядеть вот так:
![Pull request flow Pull request flow](https://habrastorage.org/getpro/habr/upload_files/1ab/90c/6d0/1ab90c6d0b4a2c5520d3e990e04fc2f9.png)
Теперь мы собираем релизные apk только когда нам нужно проверять размер приложения(в зависимости от измененных файлов). Что позволяет не нагружать CI, как показывает практика, проверка размера приложения требуется в ~30% открытых пулл реквестов.
В результате, мы все также имеем:
Автоматизированное обнаружение регрессии размера приложения на уровне pull request
Полная видимость изменения размера приложения в процессе разработки