Быстрая установка композитора

Установка композитора обычно занимает несколько минут. И в производственной среде это кажется слишком медленным. Можно ли установить композитор в каталог temp, а затем переключить его? Если это возможно, время простоя должно быть около нуля.

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

ОТВЕТЫ

Ответ 1

Я создал плагин для загрузки пакетов параллельно.
https://packagist.org/packages/hirak/prestissimo

$ composer global require hirak/prestissimo

Попробуйте. В моей среде composer install становится в 10 раз быстрее.

Ответ 2

Иногда вы можете значительно --prefer-dist composer install, используя флаг --prefer-dist, который просто рекомендуется для использования в производстве:

--prefer-dist: Реверс --prefer-source, композитор будет устанавливать с dist, если это возможно. Это может ускорить установку существенно на серверах сборки и в других случаях использования, где обычно не выполняется обновление поставщиков.

composer install документы здесь: http://getcomposer.org/doc/03-cli.md#install

Отредактировано для уточнения Иногда

Я говорю, что это иногда ускоряет composer install потому что в нем есть много факторов, которые чувствуют себя медленными, не последними из которых являются производительность сети и текущий статус Github. Медленная установка может быть действительно разочаровывающей, но это не всегда b/c Composer.

Ответ 3

Вы задаете две разные и несвязанные вещи.

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

Вот как работают скрипты развертывания:

  1. подготовьте следующую версию сайта в отдельном каталоге (скажем, /var/www/new); следующий список предметов и их порядок не являются статичными, некоторые проекты нуждаются в другом потоке:
    • получить последнюю версию кода из репо;
    • удалите файлы, которые не нужны на реальном сайте (.gitignore, файлы проекта IDE, заполнители и т.д.);
    • запустить composer install;
    • копировать/генерировать конфигурационные файлы, содержащие настройки для живых серверов (те, которые хранятся в репозитории, содержат фиктивные значения);
    • изменить пользователя и разрешения всех файлов; сделать некоторые каталоги доступными для веб-сервера;
    • создавать символические ссылки, каталоги и т. д.; например, каталог, содержащий загруженные пользователем файлы, находится где-то за пределами каталога сервера, и символическая ссылка на него создается во время развертывания, чтобы сделать его контент доступным через веб-сервер;
  2. переместите живой код в сторону; Я использую mv для перемещения всего каталога (/var/www/html в /var/www/old, например);
  3. переместите подготовленную новую версию в нужное место (mv/var/www/new/var/www/html);
  4. переместите предыдущую версию в архив (после удаления содержимого vendor и других файлов, которые не меняются или являются внешними).

Преимущества:

  • время простоя равно нулю (микросекунды, возможно, между этапами № 2 и № 3);
  • неудачная сборка не влияет на живой сайт (если правильно обрабатывается);
  • возврат к предыдущей версии (при необходимости) может быть легко выполнен.

Что касается другого вопроса, единственный способ, которым я знаю ускорить composer, - это не запускать его с помощью PHP, который загружает расширение xdebug. Расширение xdebug не должно быть загружено на производственный сервер в любом случае.