it-swarm.com.ru

Как правильно выполнить развертывание при использовании коммутатора разработки / производства Composer?

Composer имеет возможность загружать несколько зависимостей только в процессе разработки, поэтому инструменты не будут установлены в производственной среде (на работающем сервере). Это (теоретически) очень удобно для сценариев, которые имеют смысл только при разработке, таких как тесты, fake-data-tools, отладчик и т.д.

Для этого нужно добавить дополнительный блок require-dev с инструментами, которые вам нужны в dev:

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

а затем (теоретически) загрузить эти зависимости через

composer install --dev

Проблема и вопрос:

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

Поскольку наиболее приемлемый способ развертывания - это нажать на композитор .lock (который содержит текущую настройку composer), а затем выполнить composer install на рабочем сервере, это также установит разработка вещей.

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

Примечание. Я пытаюсь создать здесь канонический Q/A, чтобы прояснить странное Composer развертывание. Не стесняйтесь редактировать этот вопрос.

145
Sliq

почему

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

Основной рабочий процесс 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> (и commit).
  • Другие идут вместе: (оформить заказ и) 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" зависимостей.

оффтопик

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

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

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

composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader
262
Jasper N. Brouwer

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

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

Зачем?

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

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

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

Команда для использования

composer install --no-dev

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

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

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

66
Sven

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

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

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

composer update --no-dev

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

composer install --no-dev

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

2
dave1010

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

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

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

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

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

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

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

2
Giovanni Silva

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

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

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


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

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

2
Abhi Beckert