В предыдущей части мы разобрали автоматизацию обнаружения регрессии андроид приложении на уровне 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 будет выглядеть вот так:

Pull request flow
Pull request flow

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

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

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

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

Комментарии (0)