Комментарии 5
Разработчик запускает проверки локально, чтобы убедиться, что всё работает.
Бедные ваши разработчики, запуском локально всех тестов предполагаю, что их машины становятся почти неюзабельными из-за сильной нагрузки на cpu+gpu на час-два (UI тесты 40 минут на CI, предположим на CI должно стоять мощнее железо чем у среднего разработчика поэтому локально будет дольше) и это время простоя оплачивает ваш бизнес как за воздух.
При 200+ фичах в месяц каждая лишняя минута проверки добавляет более 200 минут работы CI и столько же времени ожидания для разработчиков.
Еще 10 лет назад разработчики Facebook сказали, что человек не должен ждать машины, а машины должны ждать человека, поэтому они влили кучу денег в инфраструктуру для CI, чтобы разработчики писали код, а не ждали пока пройдут тесты (час их разработчика стоит очень дорого и проще вложить в железо). Пожалейте своих девелоперов и купите им больше тачек для CI и распилите тесты чтобы их можно было параллельно запускать сразу на несколько машин, тем более на Андроиде это делается очень просто через марафон (коллега у нас на работе так сделал насколько помню).
@house2008Благодарю за рекомендацию!
Счастье разработчиков является одной из целей нашей платформенной команды. Вы абсолютно правы в том, что неюзабельные тачки разработчиков во время сборки - это "плата за воздух". К счастью, мы уже решили эту проблему:
Наши разработчики не собираются локально. Для этого у нас существует собственный Fork Mirakle.
Таким образом, даже если не применять Impact-анализ и гонять все проверки - они занимают около 22 минут на холодную (Unit-тесты 20 минут и 2 минуты detekt). Как я отметил выше, повторные локальные сборки будут сильно быстрее из-за того, что будет работать Gradle-кеш. Всё это время ресурсы на машине разработчика используются минимально, и он может заниматься другими активностями. Но и это время нам удалось сократить более чем в два раза, о чём я расскажу в следующей статье.
Что касается UI-тестов, вы тоже всё верно говорите! У нас они запускаются на ферме, параллелятся через марафон, и не потребляют мощностей разработчика. Кстати, их тоже можно запускать выборочно!
Отличный материал, Денис!
Интересно твое мнение: если разработчики игнорируют запуск проверок локально, что думаешь насчет того чтобы принудительно встроить запуск detekt через git pre-commit hooks автоматически при каждом коммите? Судя по примеру из доки, проверку можно настроить только на staged файлы для быстроты.
Эдуард, Спасибо за комментарий!
Действительно, мы рассматривали идею повесить Git Hook для для Detekt, но собрали ОС с разработчиков и поняли, что далеко не всем будет удобно исправлять замечания перед каждым commit. Моё мнение, что это рабочая стратегия, если команда готова и не будет воспринимать подобные изменения в штыки.
Как ускорить проверку приложения с помощью Impact-анализа. Часть 1: статические анализаторы