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

Зачем

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

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

• composer.phar install --dev новый проект: composer.phar install --dev , json и файлы блокировки передаются в VCS.
• Другие разработчики начинают работу над проектом: проверка VCS и composer.phar install --dev .
• Разработчик добавляет зависимости: composer.phar require <package> , add --dev если вы хотите пакет в разделе require-dev (и commit).
• Другие идут: (checkout и) composer.phar install --dev .
• Разработчику нужны более новые версии зависимостей: composer.phar update --dev <package> (и commit).
• Другие идут: (checkout и) 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 

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

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

Зачем?

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

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

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

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

 composer install --no-dev 

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

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

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

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

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

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

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

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

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

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

Теперь require-dev включен по умолчанию, для локальной разработки вы можете выполнить composer install composer update и 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 не является большим накладным расходами.

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

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

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

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

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