Как мы меняли разработку лучшего* мобильного банка под требования бизнеса

Конец 2019 года

Мобильный банк Tinkoff признан лучшим с точки зрения ежедневного банкинга агентством MarksWebb — а значит с точки зрения продукта все идет отлично. Если же смотреть с технической точки зрения, то можно выделить следующие части: команду, процессы, архитектуру и инфраструктуры. Давайте последовательно по ним пробежимся.

  • Было несколько основных продуктов —в их пользу приоритизировались ресурсы команды
  • Команда была относительно небольшой — порядка 50 человек — получалось вручную управлять процессами и приоритетами
  • Основной фокус на расширении функциональности приложения — Команда в приоритете пилит бизнес фичи и техдолг копится
  • Крупные и непериодические релизы устраивали бизнес

Что изменилось

В конце 2019 года было официально объявлено о запуске суперприложения Tinkoff, которое будет решать практически любые задачи человека в области финансов, досуга и лайфстайла. А это значит, что мы должны параллельно развивать все продукты, а не фокусироваться на нескольких основных продуктах, которые уже были классно представлены в мобильном банке. Ниже представлен timeline развития группы компаний.

Как мы решили это учесть

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

Как мы к этому приспособились

Проще всего это анализировать в разрезе команд и релизов. С учетом большого количества команд мы хотели унифицировать их путем внедрения общих правил, которые делятся на процессные и технические. Процессы очень важны и мы поговорим про них в следующий раз, так как все изменения должны быть интегрированы в ежедневную работу команд. Технические правила можно контролировать в рамках CI/CD пайплайнов. Также если мы говорим про разделение на отдельные команды, то важно, чтобы они были максимально автономными, а это возможно в случае правильной архитектуры приложения, которое разделено на модули по областям ответственности команд.

  • занимаясь жестокими мерджами отдельных веток с готовыми задачами в релизную ветку — это плохо масштабируется
  • разрабатывая с использованием trunk base development, но закрывать фичи флагами, которые включаются только при готовности фичи

Архитектура

Здесь в первую очередь важно разделение приложения на модули, которых существует 2 типа:

  • Общие модули, например, common-di, common-util, common-db, common-api, которые относятся к базовой функциональности приложения и нужны всем командам. За эти модули отвечают платформенные команды
  • Фичевые модули, которые специфичны для каждой feature команды и содержат business specific код, который реализует те сценарии, которые нужны для банковских, страховых, инвестиционных и т.д. продуктов. У одной feature команды может быть целая группа своих модулей и они за них отвечают.

Качество

Вопросы обеспечения качества всегда стояли остро, но с разделением по командам эти вопросы вышли на новый уровень. В итоге, мы перешли от чеклистов, которые были не в лучшей форме, к описанию в виде тест кейсов. Причем пришлось написать такое их количество, что они стали тянуть на тестдолг (по аналогии с техдолгом). Собственно этот тестдолг надо было отдавать и желательно в автоматизированном виде.

Мобильный Devops

Здесь важно, что увеличилось количество команд, людей в командах и они начали генерировать больше сборок. Агрессивная автоматизация тестирования привела к возросшей нагрузке от прогона тестов. Поэтому CI/CD пайлайны и инфраструктуру по ним требовалось активно дорабатывать, чтобы успевать вывозить все ожидания, а лучше вообще снизить время сборки и прогонов тестов, чтобы их можно было запускать почаще.

Итоги

Если подводить итоги, то можно сказать, что

  • Требования бизнеса поменялись
  • Нам пришлось редизайнить структуру команд
  • Это привело к перепроектированию
  • — Процессов разработки
  • — Архитектуры приложения
  • — Подходов к тестированию
  • — И инфраструктуре
  • Все эти изменения взаимосвязаны + реализуются параллельно

Параллели между развитием back, web и mobile

По-факту, все эти подходы к построению систем нужны были для борьбы со сложностью и попыток ее обуздания. Под бекенд разработкой я имею в виду больше веб сервисы с публичным api, которое в свое время пытались проектировать с использованием SOA (Service Oriented Architecture). SOA было слишком сложным и не полетело, но на смену ему пришел микросервисный подход, который получив поддержку от devops подходов и современной инфраструктуре полетел отлично. В итоге, распил монолита на микросервисы стал стандартным решением для развития и эволюции legacy систем.

Источники

  1. Выступление на Teamlead Conf 2018 про работу команд
  2. Выступление на ArchDays 2019 про изменение в архитектуре нашего публичного веб
  3. Обзор книги «SRE практики в разработке мобильных приложений»
  4. Статья «Как сделать API удобным для клиентов, особенно мобильных»
  5. Статья «Платформенные команды — что это такое и зачем они нужны»
  6. Статья «Ускоряем разработку: стандартный способ “в лоб” и более эффективный способ “сначала немного подумав”»
  7. Статья «Смена парадигмы работы с требованиями при переходе от квартальных релизов к двухнедельным»
  8. Статья «Эффективное взаимодействие продуктовых и платформенных команд разработки или “давайте жить дружно” © Леопольд»

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Alexander Polomodov

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.