Внутренний open-source. Как разрабатывать мобильное приложение большим количеством разработчиков, не потеряв в качестве / Павел Соломин (Сбербанк-Онлайн)
•
1 like•1,153 views
HighLoad++ 2017 Зал «Кейптаун», 8 ноября, 12:00 Тезисы: http://www.highload.ru/2017/abstracts/3120.html Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки. Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим. ...
Внутренний open-source. Как разрабатывать мобильное приложение большим количеством разработчиков, не потеряв в качестве / Павел Соломин (Сбербанк-Онлайн)
- 1. Внутренний Open Source Павел Соломин, Сбербанк Как разрабатывать мобильное приложение большим количеством разработчиков, не потеряв в качестве
- 2. Что такое Сбербанк Онлайн? 2 больших приложения под iOS и Android Миллионы пользователей ежедневно Значимый для клиента функционал Стратегия — развитие Super App
- 3. Заказчики доработок в приложении — подразделения по всему банку Одна небольшая команда, которая разрабатывает приложение Как была построена разработка раньше:
- 4. Проблемы этого подхода Скорость разработки одной команды ограничена Каждый из заказчиков тянет одеяло на себя
- 5. Трансформация Теперь команд, разрабатывающих сервисы для СБербанк Онлайн, становится все больше и больше — и они по всему банку
- 6. Проблема — разработчики мешают друг другу КАРТЫ ПЕРЕВОДЫ ПЛАТЕЖИ АВТОПЛАТЕЖИ
- 7. модули Слабосвязанная архитектура ЕФС БИБЛИОТЕКА КОМПОНЕТОВ ранилище UIKit Common Helpers Chains Logger Аналитика История Платежи Internal, Rur, Jur, Provider Автоплатежи список и операции Вклады список и операции П РИ КЛАД Н Ы Е СЕРВИ СЫ Б И ЗН ЕС М О Д УЛ И Карты список и операции
- 8. Проблемы команд разработки Нет продуктовой экспертизы Нет экспертизы разработки Целостность итогового продукта
- 9. Платформенные команды Делают переиспользуемые компоненты и архитектуру Смотрят за целостностью Выпускают релизы
- 11. Продукт для команд разработки Гайды Кодстайл Изоляция модулей Ежедневные пулл-реквесты Возможность отключения модуля из релиза, если не готов Покрытие тестами
- 12. Дублирование, команды разрабатывают в колодцах Платформенные команды — бутылочное горлышко Проблема
- 13. Open source model Команды могут дорабатывать не только собственные модули, но и любые необходимые им модули, договорившись с их владельцами
- 14. Platform + opensource? Для разработки платформы те же подходы — каждый разработчик может доработать ядро, договорившись с платформенными командами.
- 15. Демо => митапы
- 16. Гайды => портал Возможность заводить issue, комментировать их, открыто приоритизировать, брать в работу
- 18. Переписываем приложение Учим другие команды его разрабатывать Убираем все возможные «бутылочные горлышки» Продолжаем выпускать релизы Summary
- 19. Вопросы???