TechLead Conf · 30 июня 2021
Как меняли разработку мобильного банка под бизнес
Взгляд CTO, который отвечает не только за решение, но и за его внедрение
/ Разработка мобильного банка под бизнес · TechLead Conf 2021
Взгляд CTO, который отвечает не только за решение, но и за его внедрение
Взгляд CTO, который отвечает не только за решение, но и за его внедрение
План выступления
Как было до 2020 года
Что поменялось и как мы это учли
Как внедряли: команды, архитектура, качество
Триггеры, итоги и что почитать
Конец 2019 года
Команда, процессы и архитектура на конец 2019 года
Одна общая IT-команда с общей приоритизацией
Крупные релизы примерно раз в квартал
Монолитное приложение по горизонтальным слоям
И Mother API — монолит на Scala
Дизайн соответствовал тому бизнесу, который был
Было несколько основных продуктов
Команда была небольшой — порядка 50 человек
Фокус был на расширении функциональности
Крупные непериодические релизы устраивали бизнес
Бизнес вырос, структура IT изменилась
Развитие группы Tinkoff и структуры IT
2007–2020: от Tinkoff Black до SuperApp
Бизнес-вертикалей стало шесть
Над инфраструктурой выросли платформы
У каждой вертикали — свой темп
Платформа мобильного банка
Шесть заказчиков — шесть feature-команд
Release и Platform — общая поставка и модульность
Design & Improvements — общий UI
Performance и Reliability — общие качества
Релизный поезд
Команды должны работать независимо
Релиз уходит по дате
Не успел — едешь в следующем
Состав релиза перестал быть обещанием
Закон Конвея и brownfield, а не greenfield
Организации проектируют системы по своим коммуникациям
Желаемая структура команд поменялась
Значит, систему надо перепроектировать
Бизнес не готов к паузам — редизайним эволюционно
Команды, архитектура, качество, Mobile DevOps
Унификация и автономность
Процессные правила: delivery management и релизы
Технические: модуль per команда и контроль в CI/CD
Автономность даёт модульность приложения
Из этого выросли три направления работ
Разделение на модули
Модули фичевых команд — по доменам
Общие модули — ответственность платформенных
Внутри модуля три слоя
Моноприложение собирается под конкретную команду
Обеспечение качества
Тестовая модель: чек-листы → тест-кейсы
Описали тест-долг по существующей функциональности
Пирамида: unit, интеграционные, UI, end-to-end
Плюс метрики качества, crowdtesting и контрактное тестирование
Mobile DevOps
Больше билдов и автотестов — доработали инфру CI/CD
Появились требования к коду, стилю и архитектуре
Автоматизировали проверки: Danger для iOS, Sonar для Android
Добавились клиентский мониторинг и feature toggles
Роль и алгоритм работы
Data-driven менеджер изменений
Отвечает за E2E-процесс поставки ценности
Сокращает TTM и увеличивает прогнозируемость
Год: от плана изменений до консультирующего режима
Когда пора менять команды у себя
И симптомы, по которым их видно
Софт стал слишком большим для одной команды
Темпы поставки устойчиво замедлились
Бизнес-сервисы опираются на разрозненные нижележащие
Каждый триггер виден по своим симптомам
Типы команд и взаимодействий
Stream-aligned — бизнесовые feature-команды
Platform — платформенные команды мобильного банка
Взаимодействие — X-as-a-Service
Топология зависит от размера и зрелости
Что у нас получилось в итоге
Требования бизнеса поменялись
Триггеры потребности в эволюции команд сработали
Пришлось редизайнить структуру команд
И вместе с ней процессы, архитектуру, качество и CI/CD
Все эти изменения взаимосвязаны и идут параллельно
Именно это добавляет сложности и интереса происходящему
Мысли о схожей эволюции подходов
Монолитный бэкенд распиливается на микросервисы
Монолитный фронтенд — на микрофронтенды
Монолитное мобильное приложение — на модули
Меняется словарь, а не сам ход
Ссылки с финального слайда доклада
Книга «Team Topologies» и саммари в трёх частях
Обзор «SRE-практики в разработке мобильных приложений»
Статьи про платформенные команды и удобный API
Прошлые доклады: Teamlead Conf 2018 и ArchDays 2019
polomodov.tech
Все слайды и ссылки — в Telegram-канале
Александр Поломодов, Technical Director & Fellow, Т-Технологии
@book_cube