- PVSM.RU - https://www.pvsm.ru -

Open source: CI-CD и тестовая инфраструктура Авито для Android

Мы вынесли в open source инфраструктуру Авито для Android: Gradle плагины, эмуляторы и библиотеки для тестов. Наш код [1] будет полезен при автоматизации CI/CD, а также облегчит написание и поддержку автотестов.

В этой обзорной статье мы расскажем, почему решили сделать свою работу открытой, о наиболее значимых библиотеках проекта и сориентируем, куда идти с возникающими вопросами. Детально разберём отдельные библиотеки, Gradle-плагины и наши подходы к разработке в следующих материалах.

Open source: CI-CD и тестовая инфраструктура Авито для Android - 1

Кто мы такие и чем занимаемся

Мы работаем на Android-направлении в платформенной команде Speed. Нас четыре человека:

Серёжа Боиштян
Senior engineer
Твиттер-аккаунт [2]

Open source: CI-CD и тестовая инфраструктура Авито для Android - 2

Дима Воронин
Lead engineer
Твиттер-аккаунт [3]

Open source: CI-CD и тестовая инфраструктура Авито для Android - 3

Женя Кривобоков
Senior engineer
Твиттер-аккаунт [4]

Open source: CI-CD и тестовая инфраструктура Авито для Android - 4

Даниил Попов
Senior engineer
Твиттер-аккаунт [5]

Open source: CI-CD и тестовая инфраструктура Авито для Android - 5

Мы отвечаем за то, чтобы быстрее доставлять изменения во всех Android-приложениях Авито до пользователей. В нашу зону ответственности входят:

  • Локальная работа с проектом: чтобы всё быстро собиралось и IDE не тормозила.
  • CI pipeline: тесты, все возможные проверки.
  • CD: инструменты для релиз-инженеров.

Зачем нам нужен open source

Мы хотели не просто отзеркалить код в открытом репозитории на Гитхабе, а сделать это с пользой для себя и инженерного сообщества. Основных причин вынести проект в open source — пять:

  • Получить обратную связь.
  • Влиять на стандарты в индустрии.
  • Научиться новому.
  • Влиять на сторонние библиотеки.
  • Прокачать личный бренд.

Давайте коротко по ним пройдёмся.

Получить обратную связь и сделать код проще для повторного использования

Мы делаем тулинг для инженеров Авито, и нашим пользователям нужно, чтобы все решения просто работали. Нам не хватает взгляда со стороны от разработчиков, которые решают похожие задачи. Будет круто, если нам укажут на проблемы во внутренней реализации и удобстве подключения к нашему проекту.

Мы уже увидели, как перенос кода в Гитхаб подсветил проблемы переиспользования. Когда понимаешь, что этим могут пользоваться другие компании, то по-другому смотришь на архитектуру. Переиспользование кода — не самоцель. Но этот внешний критерий многое говорит о качестве архитектуры и её гибкости.

Влиять на стандарты в индустрии

Мы развиваем инфраструктуру для мобильных приложений c 2017 года и регулярно рассказываем об этом на конференциях и митапах:

Помимо рассказов, мы всегда хотели поделиться кодом и дать возможность его переиспользовать. Ведь многие Android-разработчики сталкиваются с похожими вызовами:

  • Как писать автотесты, чтобы они приносили пользу.
  • Как запускать их в pull request’ах.
  • Как дешевле поддерживать инфраструктуру.

Для этих задач нет общепринятых и устоявшихся решений — каждая компания действует по-своему. Мы делимся своими наработками, чтобы в новых проектах разработчикам не приходилось собирать по крупицам информацию о тестировании мобильных приложений и построении CI/CD. Хочется, чтобы вместо написания своего велосипеда можно было взять готовые решения для рутинных проблем. И, даже если кодом проекта в исходном виде никто не воспользуется, разработчики смогут подсмотреть наши подходы и улучшить собственные библиотеки.

Научиться, объясняя другим

Просто вынести код в open source — недостаточно. Важны практики, подходы, пути поиска проблем и принятия решений. Показывая их, мы проверяем, насколько наши идеи и готовые предложения работают вне Авито.

Влиять на сторонние библиотеки и быстрее исправлять их проблемы

Представьте, что вы столкнулись с проблемой в Android или библиотеке и не можете найти обходной путь. Вам нужна помощь сообщества или авторов кода. Вы задали вопрос на Stack Overflow, создали баг в Google IssueTracker, всё подробно описали, но проблема не воспроизводится. У вас просят тестовый пример. На всё это уходит дополнительное время.

Open source помогает быстрее создать воспроизводимый пример. У нас есть тестовое приложение [11], в котором используется часть инфраструктуры. Главная его задача — dogfooding, то есть как можно раньше проверить на простом и изолированном примере, что всё работает. Но это же приложение позволяет проще показывать баги. Когда мы даём воспроизводимый пример в чужой библиотеке, её автору проще понять, в чём дело. Это повышает шансы, что он возьмётся за доработки.

Популярность open source проекта тоже повышает вероятность, что на вас обратят внимание. Указание на проблему в библиотеке с кучей звёздочек и пользователей повышает давление, её сложнее игнорировать. Получить такой результат без open source сложнее — твоё приложение должно быть суперпопулярным или тебя должны знать лично.

Пиар и личная мотивация

Последняя, но не по значимости, причина — это личная выгода. От публичности ежедневной работы выигрывают все. Компания привлекает внимание за счёт полезного продукта, а мы прокачиваем личный бренд как инженеры и получаем дополнительную мотивацию для работы. Больше не нужно выискивать по вечерам время на собственные проекты или коммиты в сторонние open source библиотеки.

Что вынесли в open source

Мы вынесли в репозиторий на Гитхабе [1] почти всю нашу инфраструктуру тестирования Android и CI/CD. Чтобы другим разработчикам проще было сориентироваться в проекте, все модули сгруппированы по назначению:

Open source: CI-CD и тестовая инфраструктура Авито для Android - 6

Отмечу парочку наиболее значимых библиотек.

Test runner

Это gradle плагин для запуска instrumentation тестов. Ближайший аналог — Marathon [15], но наш написан только под Android.

Test runner: [16]

  • Описывает, какие тесты запускать. Есть фильтрация по аннотациям, по пакетам, по результатам прошлого запуска.
  • Описывает, на каких эмуляторах прогонять тесты. Резервирует их в Kubernetes или подключается к локальным эмуляторам.
  • Задаёт условия перезапуска тестов.
  • Отправляет итоговый отчет с результатами прогона тестов.

Результаты хранятся в кастомной TMS (test management system), её нет в open source. Мы работаем над тем, чтобы можно было подключить другую реализацию.

Open source: CI-CD и тестовая инфраструктура Авито для Android - 7

Impact analysis

У нас около 1600 instrumentation тестов и 10K unit-тестов. Мы хотели бы запускать все тесты на любое изменение кода, но это невозможно — прогон займёт слишком много времени.

Простое решение — вручную разделить тесты на разные наборы, например, smoke-тесты, быстрые, медленные, и запускать только часть. Но при таком подходе всегда есть шанс пропустить ошибку, потому что непонятно, какой набор тестов оптимальнее. Идеальное решение — понять, какой минимальный набор тестов проверит все изменения. Это называется test impact analysis [17].

Мы написали Gradle plugin [18], который ищет изменения в модулях, парсит тесты и определяет, какие из них запустить.

Open source: CI-CD и тестовая инфраструктура Авито для Android - 8

Более подробно основные модули и подходы описаны в документации проекта [19].
Сейчас она не очень хороша, да ещё и не вся переведена. Мы хотим сделать документацию понятнее, и нам нужна ваша помощь. Расскажите, что доработать и поправить в тексте в нашем телеграм-чате [20].

Open source: CI-CD и тестовая инфраструктура Авито для Android - 9

Чем могут быть полезны наши библиотеки

Поскольку в проекте много составляющих, его использование зависит от ваших потребностей. Если вы решаете похожую задачу или просто хотите разобраться в технологии — смело пишите нам в телеграм-чат на русском [20] или на английском [21]. Расскажем, что знаем, постараемся помочь и показать релевантные примеры.

Можно спрашивать что угодно:

  • А как вы работаете с нестабильными тестами?
  • Зачем так много кода? Он же бесполезный.
  • Почему весь код в Gradle плагинах, а не в Python скриптах?

Если вы хотите использовать какой-то конкретный модуль, то можно попробовать его в тестовом приложении [11]. Сейчас в нём показан пример использования test runner.

К сожалению, у нас пока мало примеров переиспользования в других проектах, поэтому при интеграции могут проявиться ещё неизвестные ограничения. Напишите нам, если такое произойдет, и мы посмотрим, что нужно доработать.

Заключение

В следующих статьях мы планируем рассказать про:

  • Наш test runner.
  • Анатомию теста — что происходит от нажатия кнопки “Run” в IDE до получения результата.
  • Как мы боремся c нестабильностью тестов и инфраструктуры.
  • Наши подходы к написанию инфраструктуры.
  • Как мы сократили время релизов с месяца до недели.

Есть идеи и по более общим темам:

  • Как начать писать тесты.
  • Основы тестирования для новичков — про общие подходы и технологии.

Расскажите в комментариях, о чём вам будет интереснее узнать. Так мы поймём, какой текст писать в первую очередь.

Автор: Евгений Кривобоков

Источник [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