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

<p>composer имеет возможность загружать несколько зависимостей только в процессе разработки, поэтому инструменты не будут установлены в производственной среде (на работающем сервере). это (теоретически) очень удобно для сценариев, которые имеют смысл только при разработке, таких как тесты, fake-data-tools, отладчик и т.д.</p><p>для этого нужно добавить дополнительный блок <code>require-dev</code> с инструментами, которые вам нужны в dev:</p><pre><code>"require-dev": { "codeception/codeception": "1.6.0.3" } </code></pre><p>а затем (теоретически) загрузить эти зависимости через</p><pre><code>composer install --dev </code></pre><h2>проблема и вопрос:</h2><p>composer значительно изменил поведение <code>install</code> и <code>update</code> в 2013 году, теперь по умолчанию установлены <code>require-dev</code>- зависимости, не стесняйтесь создавать composer.json с блоком <code>require-dev</code> и выполнять <code>composer install</code> для воспроизведения.</p><p>поскольку наиболее приемлемый способ развертывания - это нажать на композитор .<strong>lock</strong> (который содержит текущую настройку composer), а затем выполнить <code>composer install</code> на рабочем сервере, это также установит разработка вещей.</p><p>как правильно развернуть это <em> без </em> установки зависимостей -dev?</p><p><sub>примечание. я пытаюсь создать здесь канонический q/a, чтобы прояснить странное composer развертывание. не стесняйтесь редактировать этот вопрос.</sub></p>

<p><strong>почему</strong></p><p>имхо есть веская причина, по которой composer в настоящее время будет использовать флаг <code>--dev</code> (при установке <em> и </em> и (- === -). composer в основном запускается в сценариях, где это желаемое поведение:</p><p>основной рабочий процесс composer выглядит следующим образом:</p><ul> <li>запущен новый проект: <code>composer.phar install --dev</code>, файлы json и lock передаются в vcs.</li> <li>другие разработчики начинают работать над проектом: проверка vcs и <code>composer.phar install --dev</code>.</li> <li>разработчик добавляет зависимости: <code>composer.phar require <package></code>, добавьте <code>--dev</code>, если вы хотите пакет в разделе <code>require-dev</code> (и зафиксируйте).</li> <li>другие идут вместе: (оформить заказ и) <code>composer.phar install --dev</code>.</li> <li>разработчик хочет иметь более новые версии зависимостей: <code>composer.phar update --dev <package></code> (и commit).</li> <li>другие идут вместе: (оформить заказ и) <code>composer.phar install --dev</code>.</li> <li>проект развернут: <code>composer.phar install --no-dev</code></li> </ul><p>как видите, флаг <code>--dev</code> используется (намного) больше, чем флаг <code>--no-dev</code>, особенно когда число разработчиков, работающих над проектом, растет.</p><p><strong>развертывание производства</strong></p><blockquote> <p>как правильно развернуть это без установки зависимостей "dev"?</p> </blockquote><p>ну, файл <code>composer.json</code> и <code>composer.lock</code> должен быть зафиксирован в vcs. не опускайте <code>composer.lock</code>, поскольку он содержит важную информацию о версиях пакетов, которые следует использовать.</p><p>при выполнении производственного развертывания вы можете передать флаг <code>--no-dev</code> в composer:</p><pre><code>composer.phar install --no-dev </code></pre><p>файл <code>composer.lock</code> может содержать информацию о dev-пакетах. это не важно флаг <code>--no-dev</code> гарантирует, что эти dev-пакеты не установлены.</p><p>когда я говорю "развертывание производства", я имею в виду развертывание, нацеленное на использование в производстве. я не спорю, должен ли <code>composer.phar install</code> быть сделан на производственном сервере или на промежуточном сервере, где вещи могут быть рассмотрены. это не предмет этого ответа. я просто указываю, как <code>composer.phar install</code> без установки "dev" зависимостей.</p><p><strong>оффтопик</strong></p><p>флаг <code>--optimize-autoloader</code> также может быть желателен на производстве (он генерирует карту классов, которая ускорит автозагрузку в вашем приложении):</p><pre><code>composer.phar install --no-dev --optimize-autoloader </code></pre><p>или когда автоматическое развертывание выполнено:</p><pre><code>composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader </code></pre>

<h3>на самом деле, я очень рекомендую против установки зависимостей на рабочий сервер.</h3><p>я рекомендую извлекать код на компьютере развертывания, устанавливать зависимости по мере необходимости (это не включает установку зависимостей dev, если код поступает в производство), а затем перемещать все файлы на целевой компьютер.</p><p>зачем?</p><ul> <li>на виртуальном хостинге вы не сможете получить доступ к командной строке</li> <li>даже если вы это сделали, php может быть там ограничен с точки зрения команд, памяти или доступа к сети</li> <li>инструменты cli репозитория (git, svn), скорее всего, не будут установлены, что приведет к сбою, если ваш файл блокировки записал зависимость для извлечения определенного коммита вместо загрузки этого коммита в виде zip (вы использовали --prefer-source или composer не было другого способа получить эту версию)</li> <li>если ваша рабочая машина больше похожа на небольшой тестовый сервер (например, на микроэкземпляр amazon ec2), возможно, даже недостаточно памяти для выполнения <code>composer install</code></li> <li>в то время как composer старается ничего не нарушать, как вы относитесь к окончанию работы с частично испорченным рабочим веб-сайтом, потому что некоторая случайная зависимость не может быть загружена на этапе установки composers?</li> </ul><p>короче говоря: используйте composer в среде, которой вы можете управлять. ваша машина разработки действительно подходит, потому что у вас уже есть все, что нужно для работы composer.</p><blockquote> <p><strong>как правильно развернуть это без установки зависимостей -dev?</strong></p> </blockquote><p>команда для использования</p><pre><code>composer install --no-dev </code></pre><p>это будет работать в любой среде, будь то сам рабочий сервер, или машина развертывания, или машина разработки, которая должна выполнить последнюю проверку, чтобы определить, правильно ли используется какое-либо требование dev для реального программного обеспечения.</p><p>команда не будет устанавливать или активно удалять требования dev, объявленные в файле composer.lock.</p><p>если вы не возражаете против развертывания компонентов программного обеспечения для разработки на производственном сервере, запуск <code>composer install</code> сделает ту же работу, но просто увеличит количество перемещаемых байтов, а также создаст большее объявление автозагрузчика.</p>

<p>теперь <code>require-dev</code> включен по умолчанию, для локальной разработки вы можете использовать <code>composer install</code> и <code>composer update</code> без опции <code>--dev</code>.</p><p>если вы хотите выполнить развертывание в рабочей среде, вам необходимо убедиться, что в <code>composer.lock</code> нет пакетов, пришедших из <code>require-dev</code>.</p><p>вы можете сделать это с</p><pre><code>composer update --no-dev </code></pre><p>проведя локальное тестирование с помощью <code>--no-dev</code>, вы можете развернуть все для производства и установки на основе <code>composer.lock</code>. здесь вам снова понадобится опция <code>--no-dev</code>, иначе composer скажет <em> "файл блокировки не содержит информацию о require-dev" </em>.</p><pre><code>composer install --no-dev </code></pre><p><strong>примечание:</strong> будьте осторожны со всем, что может привести к различиям между разработкой и производством! обычно я стараюсь избегать require-dev везде, где это возможно, поскольку включение инструментов dev не требует больших затрат.</p>

<p>я думаю, лучше автоматизировать процесс</p><p>добавьте файл composer.lock в свой git-репозиторий, убедитесь, что вы используете <strong> composer.phar. установите --no-dev </strong>, когда вы выпускаете, но у вас есть dev на машине вы можете без проблем использовать любую команду composer, это не пойдет в производство, производство будет основывать свои зависимости в файле блокировки.</p><p>на сервере вы извлекаете эту конкретную версию или метку и запускаете все тесты перед заменой приложения, если тесты пройдены, вы продолжаете развертывание.</p><p>если тест зависит от зависимостей dev, поскольку composer не имеет зависимости области действия теста, не слишком элегантное решение может быть выполнено в тесте с компоновщиком зависимостей dev (<strong>. phar install </strong>), удалите библиотеку вендора, запустите <strong> composer.phar установите --no-dev </strong> еще раз, это будет используйте кэшированные зависимости, так быстрее. но это хак, если вы знаете концепцию областей действия в других инструментах сборки</p><p>автоматизируй это и забудь обо всем остальном, иди выпей пива :-)</p><p>ps: как и в комментарии @sven ниже, не стоит извлекать файл composer.lock, потому что это заставит composer установить работу как composer обновление.</p><p>вы можете сделать это с помощью <a href="http://deployer.org/">http://deployer.org/</a> это простой инструмент.</p>

<p>на производственных серверах я переименовываю <code>vendor</code> в <code>vendor-<datetime></code>, и во время развертывания у меня будет два каталога поставщиков.</p><p>файл cookie http заставляет мою систему выбрать нового поставщика <code>autoload.php</code>, и после тестирования я делаю атомарный/мгновенный переход между ними, чтобы отключить старый каталог вендора для всех будущих запросов, а затем удаляю предыдущий каталог через несколько дней.</p><p>это позволяет избежать любой проблемы, вызванной кэшем файловой системы, который я использую в apache/php, а также позволяет любому активному коду php продолжать использовать каталог предыдущего поставщика.</p><hr><p>несмотря на другие ответы, рекомендующие против него, я лично запускаю <code>composer install</code> на сервере, так как это быстрее, чем rsync из моей промежуточной области (vm на моем ноутбуке).</p><p>я использую <code>--no-dev --no-scripts --optimize-autoloader</code>. вы должны прочитать документы для каждого из них, чтобы проверить, подходит ли это для вашей среды.</p>