По расписанию создается новая ветка релиза, собирается apk, прогоняются все автоматические тесты. Далее тестировщик делает финальное ручное тестирование. Если блокирующих багов не найдено, то начинается процесс публикации. Публикация происходит постепенно с 1%. Если в дальнейшем будут найдены баги которые необходимо пофиксить в текущем релизе(сломалась целиком часть функционала, увидели большое количество запросов которые спамят сервер), то создаются задачи для их исправления которые будут замержены в текущий релиз, после чего он будет опубликован заново. Процесс публикации автоматизирован и требует минимальных усилий со стороны QA. В качестве CI используется TeamCity, артефакты хранятся удаленно, флешку использовать нет необходимости :) Также есть ежедневная автоматическая публикация beta версий после завершения всех тестов. Про автоматизацию релизов совсем недавно вышла статья.
Из AndroidX используем не так уж и много: AppCompat, View библиотеки(ConstraintLayout, RecyclerView, и тд), Fragment, Biometric, совсем недавно стали интегрировать Room. Планов по интеграции новых пока нет.
Процесс разработки новой функциональности начинается с задачи от продукт-менеджера. Он полностью описывает, как должен работать новый функционал, условия, при которых этот функционал должен активироваться, базовые тексты.
Дальше в работу вступает специальная команда MAPI, которая разрабатывает протокол общения между клиентом и сервером, описывает, как должен вести себя клиент в той или иной ситуации. Затем это проходит ревью у команд, которые будут все реализовывать. Если нужен дизайн, то дизайнер делает специальный тикет с описанием, где указано, какие компоненты из дизайн-системы нужно использовать, и какие токены для них. Это тоже проходит ревью у разработчиков.
Коммуникация, наверное, как у всех: почта, чат, трекер задач. В былые времена еще можно было подойти и обсудить что-то за чашкой чая :)
Про IT-инфраструктуру: есть разные команды которые отвечают за релиз, внутренние сервисы, тестовое окружение и так далее. Все процессы стараемся автоматизировать.
С инструментами все более-менее стандартно, разве что есть разные сервисы мониторинга, нотификации в чат, автоматизированные релизы мобильных приложений(можно прочитать тут habr.com/ru/company/badoo/blog/509238), remote builds для Android разработчиков.
По моему мнению, в процессе миграции на Kotlin нет ничего сложного. Kotlin и Java могут существовать одновременно в одном проекте, т. е. нет необходимости переписывать весь код, чтобы начать использовать Kotlin. Разве что некоторые вызовы Kotlin кода из Java могут выглядеть некрасиво, и возможно некоторое увеличение времени сборки. Мы просто стали писать новые фичи на Kotlin, оставив старый код на Java. Со временем старый код подвергается рефакторингу и переписывается уже на Kotlin.
Дальше в работу вступает специальная команда MAPI, которая разрабатывает протокол общения между клиентом и сервером, описывает, как должен вести себя клиент в той или иной ситуации. Затем это проходит ревью у команд, которые будут все реализовывать. Если нужен дизайн, то дизайнер делает специальный тикет с описанием, где указано, какие компоненты из дизайн-системы нужно использовать, и какие токены для них. Это тоже проходит ревью у разработчиков.
Коммуникация, наверное, как у всех: почта, чат, трекер задач. В былые времена еще можно было подойти и обсудить что-то за чашкой чая :)
Про IT-инфраструктуру: есть разные команды которые отвечают за релиз, внутренние сервисы, тестовое окружение и так далее. Все процессы стараемся автоматизировать.
С инструментами все более-менее стандартно, разве что есть разные сервисы мониторинга, нотификации в чат, автоматизированные релизы мобильных приложений(можно прочитать тут habr.com/ru/company/badoo/blog/509238), remote builds для Android разработчиков.
По моему мнению, в процессе миграции на Kotlin нет ничего сложного. Kotlin и Java могут существовать одновременно в одном проекте, т. е. нет необходимости переписывать весь код, чтобы начать использовать Kotlin. Разве что некоторые вызовы Kotlin кода из Java могут выглядеть некрасиво, и возможно некоторое увеличение времени сборки. Мы просто стали писать новые фичи на Kotlin, оставив старый код на Java. Со временем старый код подвергается рефакторингу и переписывается уже на Kotlin.