Добавление пакетов PHP composer в мой репозиторий git

предисловие: Jordi-я люблю композитора, продолжайте большую работу, и если я ошибаюсь в чем-либо из этого, дайте мне знать, и я обновлю свой рабочий процесс и отредактирую сообщение :D

к сожалению, это не "общая рекомендация" в зависимости от того, кого вы спрашиваете, это, безусловно, перспектива только для разработчиков. И предостережения в отношении использования практики, предписанной в FAQ composer, имеют гораздо больше соображений, чем я могу охватить здесь. Поэтому я оставлю на рассмотрение пару важных моментов. других.

С @Seldaek это собственному признанию composer на самом деле не на 100% стабилен, намного лучше, чем год назад, но все же очень активный проект независимо от. Поэтому полагаться на composer для реализации идентичной среды на сервере dev vs промежуточном сервере vs производственном сервере не было бы общей рекомендацией от любой группы QA / Deployment. Это не означало, как неуважение к Джорди, но скорее выражение maticulous характер ОК народов.

из FAQ говорится, что при слиянии библиотек поставщиков в ваш собственный репозиторий вы должны:

ограничьте себя установкой помеченных выпусков (без версий dev)

однако если вы используете composer для управления своим CI или автоматическими развертываниями, то применяется то же ограничение-только более - потому что развертывание тега master или dev в рабочей среде может быть очень другой пакет, чем то, что вы тестировали в постановке всего день или даже час назад.

даже за пределами изменений, внесенных в сторонние библиотеки (которые будут решены с помощью только помеченных версий независимо от развертывания dev или производства), если вы не можете полагаться на composer, делая то же самое каждый раз, вы рискуете ввести ошибки в производство. Это на самом деле не риск-случай, который я бы беспокоился, но опять же я разработчик тоже ;) но проблемы могут возникнуть из простые изменения такой где, если вы не поддерживаете ту же самую версию composer.phar во всех средах вы действительно можете испортить промежуточный или производственный сервер.

другой важный вопрос, который у меня есть, действительно связан со всеми пунктами, перечисленными в этом разделе:

хотя это может быть заманчиво совершить его в некоторой среде, это приводит к нескольким проблемам:

Я не вижу последствий как проблемы, а вместо этого выгоды! Большой vcs репозиторий не так уж важен в современных средах с высокой пропускной способностью. И если вы не используете очень активный lib поставщика, ваши различия также не будут такими большими. Даже если они были большими, системы git/hg/dvcs все способны повторно использовать куски, сжимать куски и держать всех ваших уток подряд. Но более того, они являются предупреждением для разработчика, когда изменения вводятся в эти пакеты, и diff -w является отличным сводным представлением общих наборов изменений,особенно если вы не на тегах dev/master.

дублирование истории всех ваших зависимостей в ваших собственных VCS.

это сформулировано немного неправильно, оно не будет дублировать всю историю фиксации lib поставщика, только одну фиксацию (вашу фиксацию), охватывающую полную дельту между сейчас и в последний раз, когда вы запускали обновление composer, приводящее к изменениям. Вероятно, вы не обновляете все свои библиотеки при каждом обновлении, даже если вы не указываете отдельных пакеты. И если вы случайно обновили lib поставщика, вы можете легко вернуться, тогда как если вы сделали это на теге dev/master, и он сломал вашу среду, вам придется выяснить, какую версию вы ранее использовали, и указать тег в composer.json и обновите снова, чтобы вернуть его. git checkout /vendor/3rdpartylib --force просто мне кажется проще.

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

В идеале composer даст вам опцию config. Он может автоматически удалить .каталог git из git тянет и автоматически rm каталог (или временно mv его) перед обновлением lib, когда и только когда существует обновленная версия. И это было бы намного надежнее, чем оставлять этот ручной процесс отдельным разработчикам. Существует равное количество причин для интеграции библиотек поставщиков в репо управления версиями так что выбор действительно зависит от деталей вашей ситуации.

самая большая причина для управления версиями всех ваших файлов - это возможность надежно развернуть точный пакет, который вы тестировали в разработке, для перехода на производство, ключевая цель vcs и автоматизированных развертываний. Если вы не настроите среду разработки для использования определенных тегов для каждого пакета и не будете контролировать версию своего композитора.phar вы не должны полагаться на composer для развертывания программного обеспечения.