Как правильно развертывать при использовании Composer develop/production switch?

Ответ 1

Почему

ИМХО есть веская причина, по которой Composer в настоящее время будет использовать флаг --dev по умолчанию (при установке и обновлении). Композитор в основном запускается в сценарии, где это желаемое поведение:

Основной рабочий процесс Composer выглядит следующим образом:

• Новый проект запущен: composer.phar install --dev, файлы json и lock передаются в VCS.
• Другие разработчики начинают работать над проектом: проверка VCS и composer.phar install --dev.
• Разработчик добавляет зависимости: composer.phar require <package>, добавьте --dev, если вы хотите пакет в разделе require-dev (и зафиксируйте).
• Другие идут вместе: (оформить заказ и) composer.phar install --dev.
• Разработчик хочет иметь более новые версии зависимостей: composer.phar update --dev <package> (и коммит).
• Другие идут вместе: (Оформить заказ и) composer.phar install --dev.
• Проект развернут: composer.phar install --no-dev

Как видите, флаг --dev используется (намного) больше, чем флаг --no-dev, особенно когда число разработчиков, работающих над проектом, растет.

Развертывание производства

Какой правильный способ развернуть это без установки зависимостей "dev"?

Хорошо, файлы composer.json и composer.lock должны быть зафиксированы в VCS. Не опускайте composer.lock, поскольку он содержит важную информацию о версиях пакетов, которые следует использовать.

При выполнении производственного развертывания вы можете передать флаг --no-dev в Composer:

composer.phar install --no-dev

Файл composer.lock может содержать информацию о dev-пакетах. Это не имеет значения. Флаг --no-dev гарантирует, что эти dev-пакеты не установлены.

Когда я говорю "развертывание производства", я имею в виду развертывание, нацеленное на использование в производстве. я не спорю о том, следует ли делать composer.phar install на рабочем сервере или на промежуточном сервере, где можно что-то проверить. Это не предмет этого ответа. Я просто указываю, как composer.phar install не устанавливать зависимости "dev".

Offtopic

Флаг --optimize-autoloader также может быть желателен на производстве (он генерирует карту классов, которая ускорит автозагрузку в вашем приложении):

composer.phar install --no-dev --optimize-autoloader

Или когда автоматизированное развертывание выполнено:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

Если ваша кодовая база поддерживает это, вы можете заменить --optimize-autoloader на --classmap-authoritative. Подробнее здесь

Ответ 2

Собственно, я настоятельно рекомендую ПРОТИВ установки зависимостей на рабочем сервере.

Моя рекомендация - проверить код на машине развертывания, установить зависимости по мере необходимости (это включает НЕ установку зависимостей dev, если код переходит к производству), а затем переместить все файлы на целевую машину.

Почему?

• на общем хостинге, вы не сможете попасть в командную строку
• даже если вы это сделали, PHP может быть ограничен там с точки зрения команд, памяти или доступа к сети.
• инструменты CLI хранилища (Git, Svn), скорее всего, не будут установлены, что не удастся, если ваш файл блокировки зарегистрировал зависимость для проверки определенного коммита вместо того, чтобы загрузить это сообщение в качестве ZIP (вы использовали --prefer- источник или Composer не было другого способа получить эту версию)
• Если ваша производственная машина больше похожа на небольшой тестовый сервер (думаю, экземпляр Amazon EC2 micro), вероятно, недостаточно памяти для выполнения composer install
• в то время как композитор пытается ничего не нарушать, как вы относитесь к завершению с частично сломанным веб-сайтом, потому что некоторая случайная зависимость не может быть загружена на этапе установки композиторов.

Короче говоря: используйте Composer в среде, которую вы можете контролировать. Ваша машина разработки действительно подходит, потому что у вас уже есть все, что необходимо для работы с Composer.

Каков правильный способ развертывания без установки зависимостей -dev?

Используемая команда

composer install --no-dev

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

Команда не будет устанавливать или активно деинсталлировать требования к разработчикам, указанные в файле composer.lock.

Если вы не против развертывания компонентов программного обеспечения разработки на рабочем сервере, запуск composer install будет выполнять ту же работу, но просто увеличит количество перемещенных байтов, а также создаст более крупную декларацию автозагрузчика.

Ответ 3

Теперь require-dev включен по умолчанию, для локальной разработки вы можете сделать composer install и composer update без опции --dev.

Если вы хотите развернуть на производство, вам нужно убедиться, что composer.lock не имеет пакетов, которые пришли из require-dev.

Вы можете сделать это с помощью

composer update --no-dev

Как только вы протестировали локально с помощью --no-dev, вы можете развернуть все для производства и установить на основе composer.lock. Вам понадобится снова параметр --no-dev, иначе композитор скажет: "Файл блокировки не содержит информацию о требовании-dev".

composer install --no-dev

Примечание: Будьте внимательны ко всему, что может вносить различия между разработчиками и производителями! Обычно я стараюсь избегать require-dev, где это возможно, поскольку включение инструментов dev не является большим накладным расходами.

Ответ 4

Я думаю, лучше автоматизировать процесс:

Добавьте файл composer.lock в ваш git-репозиторий, убедитесь, что вы используете composer.phar install --no-dev, когда вы выпускаете, но на вашем компьютере разработчика вы можете использовать любую команду composer без проблем, это не пойдет на работу, производство будет основывать свои зависимости в файле блокировки.

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

Если тест зависит от dev-зависимостей, так как у composer нет зависимости от области действия теста, не слишком элегантное решение может быть выполнением теста с dev-зависимостями (composer.phar install), удалить библиотеку vendor, запустить composer.phar install - -no-dev еще раз, это будет использовать кэшированные зависимости, поэтому быстрее. Но это хак, если вы знаете концепцию областей действия в других инструментах сборки

Автоматизируй это и забудь обо всем остальном, иди выпей пива :-)

PS: Как и в комментарии @Sven ниже, не стоит извлекать файл composer.lock, потому что это заставит установку composer работать как обновление composer.

Вы можете сделать эту автоматизацию с http://deployer.org/, это простой инструмент.

Ответ 5

На рабочих серверах я переименую vendor в vendor-<datetime>, а во время развертывания будет два поставщика dirs.

HTTP файл cookie заставляет мою систему выбирать нового поставщика autoload.php, а после тестирования я делаю полностью атомный/мгновенный переключатель между ними, чтобы отключить старый каталог поставщика для всех будущих запросов, затем я удаляю предыдущий каталог дней спустя.

Это позволяет избежать любой проблемы, вызванной кэшами файловой системы, которые я использую в apache/php, а также позволяет любому активному PHP-коду продолжать использовать предыдущий каталог поставщика.

Несмотря на другие рекомендации, рекомендующие это, я лично запускаю composer install на сервере, так как это быстрее, чем rsync из моей промежуточной области (VM на моем ноутбуке).

Я использую --no-dev --no-scripts --optimize-autoloader. Вы должны прочитать документы для каждого из них, чтобы проверить, подходит ли это в вашей среде.