Cocoapods, коммитить или нет?

cocoa-pods

На сегодняшний день использование менеджера зависимостей cocoapods для ios проектов фактически является стандартом. В этой записи не будем рассматривать использование Carthage, git modules или совсем уж рагульский вариант вброса библиотек в проект вручную.

Итак зададим главный вопрос: Коммитить ли Pods папку в репозиторий? И постараемся на него ответить максимально аргументировано, дабы закрыть его навсегда.

Что бы знать куда бежим, надо определить конечную точку. Зачем мы используем менеджер зависимостей?

  • Не собирать библиотеки в проект в ручном режиме
  • Не собирать зависимости в проект в ручном режиме библиотек
  • Не решать в ручном режиме проблемы совместимости различных зависимостей
  • Иметь общее хранилище спецификаций на доступные библиотеки

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

Тут стоит немного рассказать про само устройство cocoapods. В отличии он NPM и GEM, содержит только метаинформацию о библиотеки, но не сами исходники. И принимая этот факт к сведению можно смоделировать следующие варианты использования.

Что будет если коммитить только Podfile + Podfile.lock?

Плюсы

  • Наш репозиторий содержит только наш код
  • Merge измений в Podfile гараздо проще, чем merge Pods папки (некоторые утверждают 😉

Минусы

  • Так как центральный репозиторий содержит ТОЛЬКО описание и ссылку на сам код библиотек, вероятен черный лебедь, что сама библиотека будет не доступна на момент pod install.
  • Если не указывать версию используемой зависимости, то при выходе свежей версии, можем получить нерабочий код. С проектами на objc, такие проблемы могут проявляться в рантайм, что делает их сложно выявляемыми. Решается коммитом Podfile.lock.
  • Фактически не компилирующийся код в репозитории. Испраляется костылями в виде скриптов для сборки
  • Нельзя собрать проект если нет cocoapods, который не поставляется ни с системой, ни с Xcode

Вывод: Как решение экономии времени не подходит, цель исключительно лежит в developer value, но не business value. Так как в некоторых случаях (и не нами контролируемых) мы получаем проект, где пропадает чужой репозиторий с библиотекой и мы затратим время на его восстановление. Единственный устойчивый случай, если вы контролируете исходники библиотек или делаете fork всем используемым библиотекам.

Чтоб будет если коммитить Pods папку в репозиторий?

Плюсы

  • Гарантия, что проект всегда будет собираться и работать у всех одинаково
  • Проект атомарен, собирается даже если в системе нет cocoapods (клиенты, CI)
  • Нет проблем с явными/скрытыми несовместимостями при соборке/выполнении

Минусы

  • Дополнительная папка Pods и увеличенный размер репозитория
  • Возможные проблемы при merge Pods папки

Выводы: Экономия времени, так как больше никаким образом не тратиться время на библиотеки в ущерб размеру репозитория. Совпадает с изначально поставленной задачей.

Что говорит моя практика?

  • У нас было пару случаев, когда пропадали зависимости с чужих github репозиториев. Да, проблема была решена поиском форков. Остался осадочек и нежелание тратить время в будущем
  • Единственный раз была проблема с коммитом Pods с yandex maps SDK, где скомпиленная либа не «влазила» в репо по лимитам бесплатного аккаунта
  • В 80% Pods содержит только исходники и вес в среднем в больших проектах ~50 MB
  • Часто клиент собирает проект из репозитория, но не все могут поставить cocoapods
  • Было пару случаев, когда я не смог собрать заранее склоненный проект зарание в поезде из-за отсутствия интернета
  • Merge совместных обновлений папки Pods прост как лом. Просто удаляется папка и заново делается pod install с правильными версиями библиотек. Результат коммититься в репо. Плюс, сразу обращаешь внимание на совместимость со своим кодом.
  • Больше 100 наших проектов содержат Pods папку и это дает только положительные результаты.

Спонсором написания выступило бамболео у Josser’а. Готов послушать аргументацию при использования Cocoapods, а не «у них такая же нога и совсем не болит» для NPM, Gems и иже с ними.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *