Feature Toggles, или Как выкатывать фичи без релиза / Ян Ашенкампф (KUPIVIP.RU)

• В видео рассказывается о фичу оглы - функционале, который можно добавить в приложение без релиза.  

• Ян Ашин Кампф, директор по продукту и технологиям компании Купи Вип, делится своим опытом и кейсом, связанным с фичу оглы.  

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

• Для решения этих проблем компания начала экспериментировать с архитектурой и функционалом, используя автотесты, автоматизированное развертывание и многоверсионность.  

• Компания перешла на стетлес, гибридную архитектуру, которая сочетает в себе кэш и базу данных.  

• Это позволило значительно сократить количество запросов и уменьшить пространство для ошибок.  

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

• Опыт компании может быть полезен для других компаний, которые хотят повысить эффективность и скорость разработки.  

• В видео рассказывается о переходе с MySQL на MongoDB для хранения данных в проекте.  

• MongoDB используется для построения фасетов и для обслуживания каталога товаров.  

• ElasticSearch используется для полнотекстового поиска и для обслуживания каталога товаров.  

• MongoDB и ElasticSearch используются вместе для обеспечения совместимости и поддержки разных версий.  

• Spring REST Docs используется для создания документации на основе тестов.  

• Это позволяет создавать документацию с примерами использования и проверять работу API.  

• Feature Branches используются для разделения кода на разные версии и для управления релизами.  

• Это помогает избежать конфликтов и упростить процесс разработки.  

• Feature Branches могут жить долго и требуют постоянного мержения и интеграции кода.  

• Это может быть изнуряющей и бесполезной работой для разработчиков.  

• Фича-бранчи - это отложенные изменения в коде, которые не готовы к релизу, но могут быть протестированы на продакшне.  

• Проблема с тестированием фича-бранчей заключается в том, что они не полностью тестируются и могут вызывать неожиданные результаты.  

• Использование тестовых версий позволяет разработчикам и тестировщикам тестировать функционал, не дожидаясь полной готовности кода.  

• Это позволяет сэкономить время разработки и быстрее показывать изменения заказчику.  

• Релизные фича-тоглы - это изменения в коде, которые уже готовы к релизу и интегрированы с безопасностью и протоколами обмена.  

• Добавление фича-тоглов в код очень простое и быстрое, используя готовые библиотеки.  

• Аб-тесты - это тесты, которые используют две контрольные группы для определения валидности теста.  

• Важно использовать две контрольные группы для обеспечения валидности теста.  

• Производительность, сложность тестирования и сложность кода могут быть проблемами при использовании тоглов.  

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

• Использование тоглов позволяет быстро и эффективно тестировать изменения в системе, контролировать доступ к определенным функциям и избегать проблем с совместимостью.  

• Тоглы могут быть использованы для контроля доступа к определенным функциям и тестирования изменений в системе.  

• В компании используются флаги для управления функционалом и включения/выключения определенных функций.  

• Флаги хранятся в базе данных и управляются через API.  

• Старые версии мобильных приложений обновляются, но не все пользователи переходят на новые версии.  

• Обновление приложений происходит постепенно, чтобы избежать проблем с совместимостью.  

• Пользователи могут быть включены в группу, где тестируются новые фичи, и получать уведомления о них.  

• Если пользователь не хочет новую фичу, он может быть исключен из группы тестирования.  

• Архитектура компании микросервисная, но приложение представляет собой огромный жарник, состоящий из сервисов.  

• Флаги хранятся централизованно в общем хранилище, а не на каждом сервисе.  

• Микросервисная архитектура может быть использована и в монолитной архитектуре, если это необходимо.