Поддержка старых версий мобильного клиента
Вопрос
Как вы организуете совместимость бэкенда и множества версий мобильного приложения?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Мобильные версии живут месяцами, статистика версий в аналитике
Аддитивные изменения API, версионирование эндпоинтов
Клиент устойчив к неизвестным полям и значениям enum
Флаги и удалённый конфиг для поведения
Минимальная поддерживаемая версия и мягкое и жёсткое обновление
Контрактные тесты между клиентом и сервером
Что могут спросить следом
- Как клиенту обработать неизвестный тип блока или статуса?
- Когда можно удалить старый эндпоинт?
Разбор
Исхожу из того, что в каждый момент в продакшене живут 5-10 версий приложения, и смотрю их долю в аналитике. Бэкенд меняет API аддитивно: новые поля добавляются, старые удаляются, только когда доля клиентов, которые их читают, стала ничтожной. Ломающие изменения идут через новую версию эндпоинта. Клиент со своей стороны устойчив: неизвестные поля игнорируются, неизвестные значения enum превращаются в «unknown» и обрабатываются мягко, неизвестный блок на экране пропускается. Поведение настраивается удалённым конфигом. Минимальная поддерживаемая версия есть, но поднимается редко, с мягким предупреждением заранее. Между клиентом и сервером контрактные тесты, чтобы изменения не ломали старые клиенты незаметно.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Ещё по теме «CI/CD, фича-флаги и релизы»
- Обратная совместимость API для мобильных клиентов
- Метрика стабильности релиза
- Зачем фича-флаги в мобильном приложении
- Гигиена фича-флагов
- Хотфикс мобильного приложения
- Релизный пайплайн мобильного приложения
- Принудительное обновление
- Типы фича-флагов