@house2008Благодарю за рекомендацию! Счастье разработчиков является одной из целей нашей платформенной команды. Вы абсолютно правы в том, что неюзабельные тачки разработчиков во время сборки - это "плата за воздух". К счастью, мы уже решили эту проблему: Наши разработчики не собираются локально. Для этого у нас существует собственный Fork Mirakle.
Таким образом, даже если не применять Impact-анализ и гонять все проверки - они занимают около 22 минут на холодную (Unit-тесты 20 минут и 2 минуты detekt). Как я отметил выше, повторные локальные сборки будут сильно быстрее из-за того, что будет работать Gradle-кеш. Всё это время ресурсы на машине разработчика используются минимально, и он может заниматься другими активностями. Но и это время нам удалось сократить более чем в два раза, о чём я расскажу в следующей статье.
Что касается UI-тестов, вы тоже всё верно говорите! У нас они запускаются на ферме, параллелятся через марафон, и не потребляют мощностей разработчика. Кстати, их тоже можно запускать выборочно!
Действительно, мы рассматривали идею повесить Git Hook для для Detekt, но собрали ОС с разработчиков и поняли, что далеко не всем будет удобно исправлять замечания перед каждым commit. Моё мнение, что это рабочая стратегия, если команда готова и не будет воспринимать подобные изменения в штыки.
Благодарю за Ваш интерес! К своему счастью, не столкнулся с "эффективными менеджерами", о которых Вы говорите, поэтому готового рецепта, как обосновать важность снятия метрик к меня нет. Но есть идея, откуда можно начать. Рекомендую посмотреть в сторону книги «Site Reliability Engineering. Надежность и безотказность, как в Google», (Бейер Б. Джоунс К. Петофф Д. Мёрфи Н. ). В числе прочего там описано, как количественно перевести качество в деньги.
Спасибо за статью! Стало любопытно, описанный подход применяется только к мобильным приложениям или также доступен на мобильном и десктопном вебе?
@house2008Благодарю за рекомендацию!
Счастье разработчиков является одной из целей нашей платформенной команды. Вы абсолютно правы в том, что неюзабельные тачки разработчиков во время сборки - это "плата за воздух". К счастью, мы уже решили эту проблему:
Наши разработчики не собираются локально. Для этого у нас существует собственный Fork Mirakle.
Таким образом, даже если не применять Impact-анализ и гонять все проверки - они занимают около 22 минут на холодную (Unit-тесты 20 минут и 2 минуты detekt). Как я отметил выше, повторные локальные сборки будут сильно быстрее из-за того, что будет работать Gradle-кеш. Всё это время ресурсы на машине разработчика используются минимально, и он может заниматься другими активностями. Но и это время нам удалось сократить более чем в два раза, о чём я расскажу в следующей статье.
Что касается UI-тестов, вы тоже всё верно говорите! У нас они запускаются на ферме, параллелятся через марафон, и не потребляют мощностей разработчика. Кстати, их тоже можно запускать выборочно!
Эдуард, Спасибо за комментарий!
Действительно, мы рассматривали идею повесить Git Hook для для Detekt, но собрали ОС с разработчиков и поняли, что далеко не всем будет удобно исправлять замечания перед каждым commit. Моё мнение, что это рабочая стратегия, если команда готова и не будет воспринимать подобные изменения в штыки.
Благодарю за Ваш интерес! К своему счастью, не столкнулся с "эффективными менеджерами", о которых Вы говорите, поэтому готового рецепта, как обосновать важность снятия метрик к меня нет. Но есть идея, откуда можно начать. Рекомендую посмотреть в сторону книги «Site Reliability Engineering. Надежность и безотказность, как в Google», (Бейер Б. Джоунс К. Петофф Д. Мёрфи Н. ). В числе прочего там описано, как количественно перевести качество в деньги.
Спасибо за высокую оценку проделанной работе! Постараюсь дополнить материал, по мере того как появится время!