- PVSM.RU - https://www.pvsm.ru -
Мы вынесли в open source инфраструктуру Авито для Android: Gradle плагины, эмуляторы и библиотеки для тестов. Наш код [1] будет полезен при автоматизации CI/CD, а также облегчит написание и поддержку автотестов.
В этой обзорной статье мы расскажем, почему решили сделать свою работу открытой, о наиболее значимых библиотеках проекта и сориентируем, куда идти с возникающими вопросами. Детально разберём отдельные библиотеки, Gradle-плагины и наши подходы к разработке в следующих материалах.
Мы работаем на Android-направлении в платформенной команде Speed. Нас четыре человека:
Серёжа Боиштян Senior engineer Твиттер-аккаунт [2]
|
Дима Воронин Lead engineer Твиттер-аккаунт [3]
|
Женя Кривобоков Senior engineer Твиттер-аккаунт [4]
|
Даниил Попов Senior engineer Твиттер-аккаунт [5]
|
Мы отвечаем за то, чтобы быстрее доставлять изменения во всех Android-приложениях Авито до пользователей. В нашу зону ответственности входят:
Мы хотели не просто отзеркалить код в открытом репозитории на Гитхабе, а сделать это с пользой для себя и инженерного сообщества. Основных причин вынести проект в open source — пять:
Давайте коротко по ним пройдёмся.
Мы делаем тулинг для инженеров Авито, и нашим пользователям нужно, чтобы все решения просто работали. Нам не хватает взгляда со стороны от разработчиков, которые решают похожие задачи. Будет круто, если нам укажут на проблемы во внутренней реализации и удобстве подключения к нашему проекту.
Мы уже увидели, как перенос кода в Гитхаб подсветил проблемы переиспользования. Когда понимаешь, что этим могут пользоваться другие компании, то по-другому смотришь на архитектуру. Переиспользование кода — не самоцель. Но этот внешний критерий многое говорит о качестве архитектуры и её гибкости.
Мы развиваем инфраструктуру для мобильных приложений c 2017 года и регулярно рассказываем об этом на конференциях и митапах:
Помимо рассказов, мы всегда хотели поделиться кодом и дать возможность его переиспользовать. Ведь многие Android-разработчики сталкиваются с похожими вызовами:
Для этих задач нет общепринятых и устоявшихся решений — каждая компания действует по-своему. Мы делимся своими наработками, чтобы в новых проектах разработчикам не приходилось собирать по крупицам информацию о тестировании мобильных приложений и построении CI/CD. Хочется, чтобы вместо написания своего велосипеда можно было взять готовые решения для рутинных проблем. И, даже если кодом проекта в исходном виде никто не воспользуется, разработчики смогут подсмотреть наши подходы и улучшить собственные библиотеки.
Просто вынести код в open source — недостаточно. Важны практики, подходы, пути поиска проблем и принятия решений. Показывая их, мы проверяем, насколько наши идеи и готовые предложения работают вне Авито.
Представьте, что вы столкнулись с проблемой в Android или библиотеке и не можете найти обходной путь. Вам нужна помощь сообщества или авторов кода. Вы задали вопрос на Stack Overflow, создали баг в Google IssueTracker, всё подробно описали, но проблема не воспроизводится. У вас просят тестовый пример. На всё это уходит дополнительное время.
Open source помогает быстрее создать воспроизводимый пример. У нас есть тестовое приложение [11], в котором используется часть инфраструктуры. Главная его задача — dogfooding, то есть как можно раньше проверить на простом и изолированном примере, что всё работает. Но это же приложение позволяет проще показывать баги. Когда мы даём воспроизводимый пример в чужой библиотеке, её автору проще понять, в чём дело. Это повышает шансы, что он возьмётся за доработки.
Популярность open source проекта тоже повышает вероятность, что на вас обратят внимание. Указание на проблему в библиотеке с кучей звёздочек и пользователей повышает давление, её сложнее игнорировать. Получить такой результат без open source сложнее — твоё приложение должно быть суперпопулярным или тебя должны знать лично.
Последняя, но не по значимости, причина — это личная выгода. От публичности ежедневной работы выигрывают все. Компания привлекает внимание за счёт полезного продукта, а мы прокачиваем личный бренд как инженеры и получаем дополнительную мотивацию для работы. Больше не нужно выискивать по вечерам время на собственные проекты или коммиты в сторонние open source библиотеки.
Мы вынесли в репозиторий на Гитхабе [1] почти всю нашу инфраструктуру тестирования Android и CI/CD. Чтобы другим разработчикам проще было сориентироваться в проекте, все модули сгруппированы по назначению:
Отмечу парочку наиболее значимых библиотек.
Это gradle плагин для запуска instrumentation тестов. Ближайший аналог — Marathon [15], но наш написан только под Android.
Test runner: [16]
Результаты хранятся в кастомной TMS (test management system), её нет в open source. Мы работаем над тем, чтобы можно было подключить другую реализацию.
У нас около 1600 instrumentation тестов и 10K unit-тестов. Мы хотели бы запускать все тесты на любое изменение кода, но это невозможно — прогон займёт слишком много времени.
Простое решение — вручную разделить тесты на разные наборы, например, smoke-тесты, быстрые, медленные, и запускать только часть. Но при таком подходе всегда есть шанс пропустить ошибку, потому что непонятно, какой набор тестов оптимальнее. Идеальное решение — понять, какой минимальный набор тестов проверит все изменения. Это называется test impact analysis [17].
Мы написали Gradle plugin [18], который ищет изменения в модулях, парсит тесты и определяет, какие из них запустить.
Более подробно основные модули и подходы описаны в документации проекта [19].
Сейчас она не очень хороша, да ещё и не вся переведена. Мы хотим сделать документацию понятнее, и нам нужна ваша помощь. Расскажите, что доработать и поправить в тексте в нашем телеграм-чате [20].
Поскольку в проекте много составляющих, его использование зависит от ваших потребностей. Если вы решаете похожую задачу или просто хотите разобраться в технологии — смело пишите нам в телеграм-чат на русском [20] или на английском [21]. Расскажем, что знаем, постараемся помочь и показать релевантные примеры.
Можно спрашивать что угодно:
Если вы хотите использовать какой-то конкретный модуль, то можно попробовать его в тестовом приложении [11]. Сейчас в нём показан пример использования test runner.
К сожалению, у нас пока мало примеров переиспользования в других проектах, поэтому при интеграции могут проявиться ещё неизвестные ограничения. Напишите нам, если такое произойдет, и мы посмотрим, что нужно доработать.
В следующих статьях мы планируем рассказать про:
Есть идеи и по более общим темам:
Расскажите в комментариях, о чём вам будет интереснее узнать. Так мы поймём, какой текст писать в первую очередь.
Автор: Евгений Кривобоков
Источник [22]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/android-development/351997
Ссылки в тексте:
[1] Наш код: https://github.com/avito-tech/avito-android
[2] Твиттер-аккаунт: https://twitter.com/sboishtyan
[3] Твиттер-аккаунт: https://twitter.com/DmitriVoronin
[4] Твиттер-аккаунт: https://twitter.com/eugene_kr
[5] Твиттер-аккаунт: https://twitter.com/int02h
[6] Алексей Шпирко «Релизы мобильных приложений в Авито»: https://youtu.be/r3rUedCbe7Q
[7] Дмитрий Меркурьев «Impact Analysis»: https://youtu.be/EBO2S9qcp0s?t=6948
[8] Николай Нестеров «Эволюция CI в команде мобильной разработки»: https://youtu.be/lz8MNATTUCU
[9] Алексей Шпирко «Автотесты в Авито. Зачем они, как помогают, сколько стоят»: https://youtu.be/25EO8E3DMPw
[10] Евгений Кривобоков «Ускорение сборки многомодульного Android-приложения»: https://youtu.be/MGczcEukjEY
[11] тестовое приложение: https://github.com/avito-tech/avito-android/tree/develop/subprojects/android-test/test-app
[12] Gradle плагины.: https://avito-tech.github.io/avito-android/docs/infrastructure/#gradle-plugins
[13] Библиотеки для Android тестов.: https://avito-tech.github.io/avito-android/docs/infrastructure/#android-testing-modules
[14] Emulators.: https://github.com/avito-tech/avito-android/tree/develop/ci/docker
[15] Marathon: https://github.com/Malinskiy/marathon
[16] Test runner:: https://avito-tech.github.io/avito-android/docs/test/runner/
[17] test impact analysis: https://martinfowler.com/articles/rise-test-impact-analysis.html
[18] Gradle plugin: https://avito-tech.github.io/avito-android/docs/ci/impactanalysis/
[19] в документации проекта: https://avito-tech.github.io/avito-android/docs/infrastructure/#buildscript-dependencies
[20] в нашем телеграм-чате: https://t-do.ru/avito_android_opensource
[21] на английском: https://t-do.ru/avito_android_opensource_en
[22] Источник: https://habr.com/ru/post/496036/?utm_source=habrahabr&utm_medium=rss&utm_campaign=496036
Нажмите здесь для печати.