Комментарии 7
Спасибо большое за статью!
Прямо космические технологии.
Прямо космические технологии.
+2
Спасибо за статью. Очень жду Zuck))
+1
Спасибо, ждал вторую часть от вас.
Насколько оправданной была разработка своего менеджера зависимостей deps для ваших внутренних модулей? Это ведь совсем не тривиальная работа, можно ли было обойтись уже существующими решениями и вокруг них строить своих логику?
Насколько оправданной была разработка своего менеджера зависимостей deps для ваших внутренних модулей? Это ведь совсем не тривиальная работа, можно ли было обойтись уже существующими решениями и вокруг них строить своих логику?
+2
Привет! На так лишь кажется. 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 при максимальной гибкости, и получилось, что создать свой инструмент — довольно быстро и недорого.
0
А возможна ситуация, когда ваш проект зависит от модулей А и B, каждый из которых зависит от модуля С, но для модуля А требуется версия С v1.1, а для модуля В — версия С v1.2?
Или у вас подразумевается, что в ветке master соответствующего модуля всегда лежит последняя версия этого модуля, и deps каждый раз при сборке проекта вытягивает изменения из master для всех модулей-зависимостей?
О, пока писал коммент, возник еще один вопрос :) При наличии 100+ модулей часто возникают проблемы обратной совместимости? Так навскидку кажется, что если в каждом из двух ваших приложений есть по 30-40 зависимостей, то чуть ли не при каждой сборке что-нибудь может сломаться.
Или у вас подразумевается, что в ветке master соответствующего модуля всегда лежит последняя версия этого модуля, и deps каждый раз при сборке проекта вытягивает изменения из master для всех модулей-зависимостей?
О, пока писал коммент, возник еще один вопрос :) При наличии 100+ модулей часто возникают проблемы обратной совместимости? Так навскидку кажется, что если в каждом из двух ваших приложений есть по 30-40 зависимостей, то чуть ли не при каждой сборке что-нибудь может сломаться.
0
gorbikvv я немного промазал с кнопкой Ответа, так что в отдельном треде получилось :)
- Для нас такая ситуация невозможна, внутренние модули не имеют версий, т.к. весь исходный код находится в одном репозитории.
- В master действительно лежит самый актуальный код всех модулей. Deps не занимается вытягиванием, исходники тащатся вместе с git pull origin master.
- В целом такая проблема есть, но она не очень заметна даже на 100+ модулях. Т.е. при разработке новой функциональности бывает, что нужно менять публичный интерфейс модуля, тогда это действительно может затронуть другие модули и приложения, но случается это не очень часто, и в целом такой подход форсирует разработку более устойчивых архитектур, с интерфейсами, которые скорее придётся расширить, чем изменить.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модуляризация iOS-приложения Badoo: борьба с последствиями