Любому продукту, который в данный момент находится в сторе, грозят релизы. Наш проект не является исключением. Мы работаем по методологии scrum, разработка делится на спринты, обычно спринты не привязаны ко времени, а делятся на временные отрезки, зависящие от скоупа спринта. По итогам спринта обычно проводится релиз приложения в стор, который включает в себя новые фичи и некоторый багфикс.

Однако, из-за специфики проекта не все фичи сразу попадают в релиз по завершению спринта. Из-за такого подхода появляются фичи, которые нельзя выпускать в прод. При всем при этом, никто не отменял критические баги, мелкие фиксы и просто выпуск готовых фич. Можно выделить несколько видов релизов:

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

В условиях постоянных релизов возникает вопрос: «Как же вести разработку?».
Ведь каждый разработчик должен делать задачи, делать ветки на эти задачи и куда-то по итогу их мерджить.

Основной инструмент любого программиста — язык программирования. Когда начинался проект мы выбрали Swift. Решили идти в ногу со временем, старый, но так горячо любимый Objective-C остался не у дел. Однако у Swift есть небольшая проблема и особенно она становится заметной, когда проект начинает расти – это проблема времени сборки проекта. Для понимания проблемы и размеров проекта, попробуем сравнить среднее время сборки за неделю на всех проектах студии.

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

Разработка мобильных приложений кажется достаточно простым занятием. Казалось бы, что там делать? Накидал парочку вьюх, помазал это какой-нибудь архитектурой, и все, проект готов, можно отправлять приложение в стор. В цикле статей я поделюсь особенностями, с которыми мы столкнулись при разработке приложения для большого банка.

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