Введение
Эта статья — первая в серии из трех. В ней мы расскажем о работе, проделанной в течение 2022 и 2023 годов и направленной на решение проблем масштабирования наших производственных приложений для iOS.
Кто мы?
Bumble Inc. является материнской компанией Bumble, Badoo, Fruitz и Official.. Платформа Bumble позволяет людям строить здоровые и равноправные отношения, используя добрые связи.
Основанная генеральным директором Уитни Вулф Херд в 2014 году, платформа Bumble стала одним из первых приложений для знакомств, в центре которого стояли женщины. Она объединяет людей на уровне знакомств (Bumble Date), дружбы (Bumble BFF) и профессионального общения (Bumble Bizz). Badoo, основанная в 2006 году, является одним из пионеров веб- и мобильных продуктов для знакомств. Fruitz, основанное в 2017 году, поощряет открытое и честное общение с помощью игривых фруктовых метафор. Official — приложение для пар, которое способствует открытому и честному общению между партнерами, было основано в 2020 году.
Для кого это?
Эта серия статей в блоге адресована командам, работающим в масштабах, схожих с нашими. Итак, каков наш масштаб?
Масштаб в Bumble Inc.
iOS-разработка в Bumble Inc. точно не маленькая! У нас есть:
- Десятки инженеров
- Сотни модулей
- 100+ рабочих пространств с фичами
- Миллионы строк Swift, с примесью ObjectiveC со старых добрых времен 🙃
- Десятки тысяч строк кастомного инструментального кода
- Много модульности, причем довольно высокого уровня
Небольшой участок нашего модульного графа
Читателям может показаться, что это довольно большой масштаб. Однако в этой серии статей мы будем рассматривать Bumble Inc. как команду среднего масштаба. Почему же?
Команды «среднего» размера
Мы выбрали терминологию «средние», чтобы подчеркнуть «промежуточное» состояние, в которое могут попасть команды в iOS-экосистеме.
- С одной стороны, есть небольшие команды — стартапы или индивидуальные разработчики. Маркетинг Apple для разработчиков часто кажется странно сфокусированным на таких командах! Они очень довольны своим предоставляемым разработчикам опытом (а почему бы и нет!).
- С другой стороны, у вас есть самые большие имена в индустрии. Вы знаете их! У них самые большие штаты разработчиков, целые созвездия продуктов и миллионы и миллионы строк кода. Эти компании могут оправдать крупные инвестиции в инфраструктурные инструменты и часто являются создателями тех самых инструментов, которые мы будем обсуждать в этой серии.
А между ними находятся команды среднего уровня: хотя Bumble, конечно, не стартап и не инди-приложение, мы также не являемся одним из гигантских гигантов. И мы не одиноки: большинство наших коллег работают в таком же масштабе.
Быть в середине
Когда проекты увеличиваются от размера стартапа или инди-компании до такого среднего масштаба, возникает слишком знакомая ситуация: ранее идеальный опыт разработчиков Apple начинает давать сбой. Что мы под этим подразумеваем?
Модульность, время сборки, Xcode
Все достаточно просто: чем больше кода, тем больше времени требуется на компиляцию, чтение, сохранение и индексацию.
Те, кто работал с большими проектами в Xcode, знают, что по мере увеличения размера проекта его производительность снижается — время открытия рабочей области, операций с файлами и, конечно же, время сборки увеличивается! Модульность может смягчить эту проблему: достаточно хорошо структурировать код, и вы сможете увеличить распараллеливание и кэширование. Но модульность должна быть легкой — если при перемещении, разделении, добавлении и удалении модулей возникает слишком много сложностей, то это не сработает.
Конечно, вы можете создавать фреймворки и настраивать проекты в Xcode. Проблема возникает, когда эти операции начинают затрагивать больше, чем несколько модулей — тогда у вас проблемы. В Xcode нет инструментов для выполнения пакетных изменений проекта. К счастью, сообщество разработчиков предоставляет множество инструментов для работы с форматом .pbxproj. В Bumble Inc. мы написали инструменты на основе XcodeProj. Хотя это и разблокировало нас, но в то же время мы получили множество кастомного инструментального кода, который нужно было поддерживать, и который был настолько гибким, насколько хватало уже реализованных функций.
Со временем начинает казаться, что это вы работаете на формат проекта Xcode, а не наоборот!
Команда и сотрудничество
Масштабирование проекта — это не только увеличение количества строк кода, но и масштабирование самой команды. Поверхность рабочего проекта должна быть увеличена, чтобы вместить все большее количество разработчиков, работающих над кодовой базой.
И снова .pbxproj демонстрирует свои ограничения: файлы проектов представляют собой текст, но описывают сложный граф объектов, что делает их едва ли пригодными для редактирования человеком и содержат много избыточности. Конфликты при слиянии могут оставить вас с проектами, которые невозможно открыть, и то же самое относится к .xibs и .storyboards. В крайнем случае можно прибегнуть к помощи текстового редактора, но это вряд ли продуктивное решение.
Но это не только у нас — эти проблемы часто встречаются и у остальных:
- With Bazel we were able to reduce build times by 70% on clean builds
- Building Faster in iOS with Bazel
- Xcodegen vs. Tuist vs. Bazel — Comparing the 3 Tools to Supercharge Your iOS Projects
Что делать?
Как мы уже говорили, команды такого размера находятся в двойном положении: традиционный рабочий процесс, ориентированный на Xcode, замедляет их скорость, но они не в состоянии делать крупные внутренние инвестиции в инфраструктуру. Поэтому такие команды вынуждены делать прагматичный выбор из готовых инструментов и тщательно изучать свои возможности.
Таким образом, на ранней стадии этого проекта в начале 2022 года iOS Core Team в Bumble Inc. оказалась в подобной ситуации. В оставшейся части этой серии статей мы рассмотрим, какие решения мы рассматривали, что выбрали и как это сработало для нас.
Специфика — где мы были
Прежде чем продолжить, мы должны проанализировать, на каком уровне мы были как команда, приступая к этому проекту.
Несмотря на то, что мы достигли пределов наших существующих решений, мы смогли использовать их с большим успехом. У нас была хорошо выстроенная архитектура, большой объем модульности и хороший уровень унификации. Мы уже создавали шаблоны типов модулей и делились их общими настройками с помощью большой сети .xcconfigs. Как уже упоминалось, мы автоматизировали работу с модулями, разбирая и изменяя .pbxproj с помощью кастомных инструментов, созданных в XcodeProj.
В остальном мы были и остаемся почти полностью в монорепо и имеем концепцию «рабочих пространств фич» (feature workspaces), которая позволяла вести разработку в стиле плейграунда вдали от всей кодовой базы, особенно для SwiftUI. У нас было едва больше десятка сторонних зависимостей и мощная инфраструктура CI и тестирования.
В общем, у нас были средства, мотивы и возможности для того, чтобы кардинально изменить наш основной рабочий процесс. Но какое решение могло бы удовлетворить наши потребности?
Цели
Что же мы искали?
- Возможность удалить и/или значительно сократить объем нашего пользовательского инструментария
- Значительно уменьшить трение, связанное с модуляцией
- (В идеале) повысить скорость сборки или, по крайней мере, поставить себя в более выгодное положение
- Открыть двери для новых идей и рабочих процессов
- Сохранить как можно больше поддерживаемости и возможности внедрять новые фичи
- Возможность удалить .xcodeproj из репозитория 😉.
Решения
В ходе наших исследовательских проектов мы рассматривали три инструмента:
- Swift Package Manager — главный инструмент распространения кода для языка Swift
- Tuist — сторонний набор инструментов для автоматизации разработки
- Bazel — простой и полнофункциональный инструмент оркестровки традиционных сборок, изначально разработанный в Google.
Важно отметить, что эти инструменты не являются эквивалентными. У них нет строго совпадающих наборов функций. Однако все они решают наши задачи, хотя и по-разному.
Swift Package Manager (SPM)
SPM был первым инструментом, который мы исследовали, и он обладает определенным «авторитетом», так как сделан самой Apple. Начиная с Xcode 11, он полностью интегрирован в набор инструментов Xcode и не требует установки. Это означает, что с нашей стороны нет необходимости в непосредственном обслуживании. Это большое преимущество, поскольку мы предпочитаем использовать инструмент, а не поддерживать его.
Некоторые читатели могут быть удивлены включением SPM, и это, вероятно, потому, что он уже имеет имидж ориентированного на управление зависимостями от сторонних разработчиков, в духе старого доброго CocoaPods. Однако, хотя вы, конечно, можете брать зависимости с Github.com и так далее, SPM также поддерживает URL-источники для файлов. Поэтому мы можем так же легко подтягивать локальные модули из нашего монорепо.
После миграции всех модулей в SPM Packages вы будете очень близки к тому, чтобы вообще отказаться от использования .xcodeproj — хотя и не совсем (подробнее об этом позже). Итак, можем ли мы просто воспользоваться готовым решением?
Это де-факто инструмент, но подойдет ли он для наших нужд?
Tuist
В отличие от SPM, Tuist — это стороннее решение. Его первая версия была выпущена в 2018 году, а версия 1.0 — в 2019-м, поэтому он еще относительно новый. Однако за это время он уже получил большую поддержку со стороны сообщества и регулярно выпускает новые версии.
По своей сути Tuist — это генератор проектов, который использует эту функциональность для создания инструментария, ориентированного на потребности именно таких команд и проектов, которые есть у нас.
Смогут ли его функции быть достаточно привлекательными, чтобы предпочесть их блестящему решению Apple?
Bazel
Bazel — это совсем другое дело. Это полноценный многоплатформенный инструмент для оркестровки сборок. То есть он не только сторонний, не созданный Apple или командой Swift, но и вообще не ориентирован непосредственно на экосистему iOS! Сам движок Bazel должен быть объединен с правилами, необходимыми для сборки и упаковки конкретных исходных данных для сборки. Кроме того, для этого нужно выучить новый язык, хотя он, скорее всего, будет немного знакомым.
Несмотря на это, Bazel открывает большие возможности и обещает несколько очень впечатляющих вещей. Кроме того, это единственное решение из трех, способное обеспечить повышенную скорость сборки в первый же день. Но это также и резкий отход от традиционного пути Xcode.
Но будет ли вся эта мощь достаточной, чтобы оправдать свою стоимость?
Что дальше
В этом посте мы рассказали о том, как мы подошли к этому проекту, какие цели ставили перед собой и какие инструменты рассматривали. В следующем посте мы расскажем о самих исследованиях и о том, что мы узнали о каждом инструменте. До встречи!