Развертывание в производственной среде с Symfony Flex и --no-dev
У меня есть несколько крупных проектов Symfony, и я заметил, что после обновления всего до Symfony 4 (Flex), когда наша автоматизация развертывания запускает свой обычный процесс:
composer install --no-dev
Мы заканчиваем с (например) этим:
Symfony operations: 2 recipes (72fad9713126cf1479bb25a53d64d744)
- Unconfiguring symfony/maker-bundle (>=1.0): From github.com/symfony/recipes:master
- Unconfiguring phpunit/phpunit (>=4.7): From github.com/symfony/recipes:master
Затем, как и ожидалось, это приводит к изменениям в symfony.lock а также config/bundles.phpплюс все, в зависимости от того, что было включено в require-dev в composer.json,
Ничего из этого точно не ломается, но досадно иметь производственное развертывание, которое больше не имеет чистого git status вывод, и может привести к путанице относительно того, что на самом деле развернуто.
Для этого есть различные обходные пути, например, я мог бы просто require скорее, чем require-dev поскольку при развертывании этого материала нет никакого реального вреда, или я мог бы опустить --no-dev часть команды Composer.
Но на самом деле, какова правильная практика здесь? Кажется странным, что нет никакого способа сказать Flex не вносить никаких изменений в конфигурацию, если вы просто развертываете заблокированную часть программного обеспечения. Это запрос функции, или я пропустил некоторые настройки здесь?
2 ответа
На короткое время это имело место в старых версиях Syfmony Flex 1.
Об этом сообщили здесь, и исправлено здесь.
Если это происходит с вами, это означает, что у вас очень старая установка, и вы должны сделать все возможное, чтобы хотя бы обновить Symfony Flex до более новой версии (Symfony Flex 1 даже больше не работает, поэтому переход на Flex 2 если можно было бы только так, или просто удалить флекс в продакшене).
Если вы развертываете в prod из своей основной ветки, вы можете вместо этого настроить ветку развертывания. И в этой ветке вы можете предотвратить слияние определенных файлов. См. Этот пост для более подробной информации. Это создает ситуацию, в которой у вас есть основная ветка, ветка версии (пример: 3.21.2), и у вас есть мастер разработки devs, работайте над ним, а затем объедините их изменения в ветку версии. Оттуда вы выбираете, что будет развернуто в Prod. (Здесь будет небольшое действие по балансировке. Вы захотите объединить все изменения dev в master, пока они не будут соответствовать вашей ветке версии, и убедитесь, что master соответствует версии после того, как вы развернули. Это добавляет немного работы, и вы должны следить за этим и т. д.)
Другой вариант - отделить ваш git-репозиторий от вашего каталога развертывания. В этом примере каталог git создается в /var/repo/site.git и каталог развертывания /var/www/domain.com и git-ловушка после получения используется для автоматического обновления каталога www после получения push-запроса в каталог repo / site. Вы очевидно запускаете composer, npm, gulp, whathaveyou в каталоге www, а каталог git остается как есть.
Не вдаваясь в коммерческие возможности, такие как приложения непрерывного развертывания, вы можете написать сценарий развертывания. Существует множество способов написания сценария оболочки, который берет один каталог и копирует его, запускает composer, запускает npm и т. Д., Все в одной команде - отделяя ваш git от ваших каталогов развертывания. Вот простой пример, который использует текущую дату и время для именования каталога, а затем символическую ссылку на каталог развертывания.