Комментарии 7
Спасибо большое за статью!
Прямо космические технологии.
Прямо космические технологии.
Спасибо за статью. Очень жду Zuck))
Спасибо, ждал вторую часть от вас.
Насколько оправданной была разработка своего менеджера зависимостей deps для ваших внутренних модулей? Это ведь совсем не тривиальная работа, можно ли было обойтись уже существующими решениями и вокруг них строить своих логику?
Насколько оправданной была разработка своего менеджера зависимостей deps для ваших внутренних модулей? Это ведь совсем не тривиальная работа, можно ли было обойтись уже существующими решениями и вокруг них строить своих логику?
Привет! На так лишь кажется. Deps не такой уж сложный инструмент, т.к. он оперирует только Build Phases c помощью библиотеки Xcodeproj. Все настройки сборки унифицированы в xcconfig, а deps лишь по «интересным» нам правилам добавляет / удаляет модули в фазах link binaries и embed frameworks.
А вот взять какой-нибудь Swift Package Manager — там нельзя, например, на Package xcconfig постоянный навесить (можно делать override при генерации отдельного проекта, но нам не подходит). Управлять настройками SPM в таком — случае — опять же придется писать какие-то скрипты чтобы обходить все модули, генерить для них проекты с кастомными параметрами сборки и т.д.
В общем, мы руководствовались идеей максимально нативной интеграции в Xcode при максимальной гибкости, и получилось, что создать свой инструмент — довольно быстро и недорого.
А вот взять какой-нибудь Swift Package Manager — там нельзя, например, на Package xcconfig постоянный навесить (можно делать override при генерации отдельного проекта, но нам не подходит). Управлять настройками SPM в таком — случае — опять же придется писать какие-то скрипты чтобы обходить все модули, генерить для них проекты с кастомными параметрами сборки и т.д.
В общем, мы руководствовались идеей максимально нативной интеграции в Xcode при максимальной гибкости, и получилось, что создать свой инструмент — довольно быстро и недорого.
А возможна ситуация, когда ваш проект зависит от модулей А и B, каждый из которых зависит от модуля С, но для модуля А требуется версия С v1.1, а для модуля В — версия С v1.2?
Или у вас подразумевается, что в ветке master соответствующего модуля всегда лежит последняя версия этого модуля, и deps каждый раз при сборке проекта вытягивает изменения из master для всех модулей-зависимостей?
О, пока писал коммент, возник еще один вопрос :) При наличии 100+ модулей часто возникают проблемы обратной совместимости? Так навскидку кажется, что если в каждом из двух ваших приложений есть по 30-40 зависимостей, то чуть ли не при каждой сборке что-нибудь может сломаться.
Или у вас подразумевается, что в ветке master соответствующего модуля всегда лежит последняя версия этого модуля, и deps каждый раз при сборке проекта вытягивает изменения из master для всех модулей-зависимостей?
О, пока писал коммент, возник еще один вопрос :) При наличии 100+ модулей часто возникают проблемы обратной совместимости? Так навскидку кажется, что если в каждом из двух ваших приложений есть по 30-40 зависимостей, то чуть ли не при каждой сборке что-нибудь может сломаться.
gorbikvv я немного промазал с кнопкой Ответа, так что в отдельном треде получилось :)
- Для нас такая ситуация невозможна, внутренние модули не имеют версий, т.к. весь исходный код находится в одном репозитории.
- В master действительно лежит самый актуальный код всех модулей. Deps не занимается вытягиванием, исходники тащатся вместе с git pull origin master.
- В целом такая проблема есть, но она не очень заметна даже на 100+ модулях. Т.е. при разработке новой функциональности бывает, что нужно менять публичный интерфейс модуля, тогда это действительно может затронуть другие модули и приложения, но случается это не очень часто, и в целом такой подход форсирует разработку более устойчивых архитектур, с интерфейсами, которые скорее придётся расширить, чем изменить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модуляризация iOS-приложения Badoo: борьба с последствиями