Более быстрый путь к развертыванию статического контента в Magento 2? Dev to Live и т.д.?

Ответ 1

да, это может быть быстрее, выполнив следующие шаги:

• Изменение файла js/css в каталоге приложения
• Теперь удалите файл формы pub/static folder

вы можете найти файл в папке static, выполнив команду

find pub/static -iname yourjsfile.js

3. удалите только тот файл, в котором вы имеете изменения из папки pub/static
4. убедитесь, что есть файл pub/static.htaccess и pub/static.php.
5. назначить права на запись файла в папку pub
6. теперь удаляет URL-адрес в браузере .htaccess будет напрямую развертывать отсутствующий файл js

.htaccess в pub/static отправляет отсутствующие файлы в pub/static.php с параметром ресурс и pub/static.php создает файл StaticResource для файла, если он доступен, и развертывает его.

Примечание: это работает только с apache mod_rewrite

Для Nginx вам нужно настроить то же самое с помощью nginx.conf.sample

Ответ 2

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

Предположим, что сайт находится в директории site.

$ cp -r site site-update

# update the site in site-update directory

$ mv site site-old && mv site-update site

Таким образом, мои сайты обновляются без каких-либо простоя.

Ответ 3

Общий комментарий:

Вы не должны делать "хрюкать" здесь, как вы это устанавливаете: static-content: deploy. Вы можете генерировать статическое содержимое для en_US (то есть без параметра) и ar_SA параллельно (bash позволяет сделать это довольно легко).

Если вы пропустили HTTPS (безопасные) ресурсы (возможно, это была причина, по которой вы использовали grunt дополнительно), убедитесь, что для переменной процесса "HTTPS" (например, HTTPS=ON) для процесса, который компилирует статический контент (ref).

Кроме того, да, это требует времени. Что привлекло внимание, так это то, что компиляция PHP меньше занимает довольно много времени. Одна из идей, которая мне пришла в голову, когда я слышала об этом от другого разработчика, заключалась в том, чтобы кэшировать меньше компиляции в локальном кэше, а только повторно компилировать, если файл действительно изменяется. Возможно, вы также можете попробовать это.

Я еще не ответственен за взлома PoC вместе, но думаю, что это должен быть хороший тест на утверждение о том, что меньшая компиляция является узким местом.

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

Ответ 4

В нашей компании мы управляем развертыванием Magento2 с помощью Capistrano, есть также специальные настройки для Magento 2, которые работают очень хорошо.

С помощью capistrano вы настраиваете корень вашего веб-сервера, указывая на символическую ссылку, указывающую на папку "release". Когда вы запускаете развертывание, вся компиляция (di, static contents, ecc) производится в отдельной папке, поэтому ваш онлайн-сайт не затрагивается и остается в сети. В конце процедуры, и только если ошибок нет, символическая ссылка переключается на новую версию.

Таким образом, время простоя обычно равно нулю или сокращается до нескольких секунд.

Capistrano также предоставляет базовую функцию отката, которая позволяет быстро вернуться к старой версии, если что-то пойдет не так.

Ответ 5

Я не коснулся setup:static-content:deploy через некоторое время. После того, как вы устали от медленного процесса развертывания в Magento 2, я разработал свой собственный, который позволяет мне вносить изменения в CSS или JS файл и отражать его почти сразу на сайте. Здесь волшебство:

cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME
find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 | xargs -I {} bash -c 'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'
cd - 1> /dev/null

Позвольте сломать его...

• cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME - перейдите в каталог активной темы (замените $VENDOR и $THEME своими собственными значениями)
• find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 - найти все файлы CSS и JS, которые каким-либо образом были изменены за последние 10 минут в каталоге тем (* избавляется от ведущего ./ в результатах); не стесняйтесь изменять любой из параметров в соответствии с вашими потребностями.
• xargs -I {} bash -c - для каждого измененного файла выполните команды в # 4-6 (относительный путь к измененному файлу хранится в {})
• dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g") - установить путь назначения развертывания
  • * glob заботится о том, чтобы соответствовать любому языку в
  • $(...) порождает подоболочку, чтобы извлечь только часть исходного пути, которую нам нужно добавить к пути назначения (web уровень каталога не существует в pub)
• echo Deploying {} to $dest ... - зарегистрируйте активность на консоли, чтобы вы знали, какие файлы развертываются.
• mkdir -p $dest && cp {} $_ - создать структуру каталога назначения; если и только если структура каталогов успешно создана, скопируйте измененный файл в пункт назначения развертывания в pub ($_ указывает на последний аргумент предыдущей команды, mkdir, который равен $dest)
• cd - 1> /dev/null - перейдите в предыдущий каталог, чтобы продолжить, где вы остановились.

Вы можете выбросить все это в псевдоним, чтобы свести его к одной команде, но не забудьте оставить одиночные кавычки:

alias update='cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME; find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 | xargs -I {} bash -c '"'"'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'"'"'; cd - 1> /dev/null'

Если вы используете лак, тогда вы должны добавить команду для перезапуска лака в конце псевдонима (например, sudo service varnish restart), или вы, вероятно, по-прежнему будете сталкиваться с кэшированными статическими активами.

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

Ответ 6

Я пришел с решением для этой проблемы.

Вы должны опубликовать содержимое магазина, который хотите,

php bin/magento setup:static-content:deploy [lang(en_US)] -t [vendor]/[theme]

Я не изменюсь, потому что magento cache, так что просто удалите его вручную

rm -rf pub/static/_*/*

php bin/magento cache:flush; php bin/magento cache:clean;

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

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

Ответ 7

Я также заметил, что если у вас есть подпись css и js, кажется, что вы пропали без вести, если вы запустили обновление установки, тогда он разрывает версию, и она выталкивает css/js, пока вы не выполните восстановление статического содержание.

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

Мне повезло с 1. Включить css/js 2. Затем вы можете запускать статический контент для развертывания, похоже, что ур довольно неплох 3. Очистить кеш (затем добавляет новую версию12312312 к статическим URL-адресам)

Но серьезно, ни в коем случае нельзя быть уверенным в развертывании.

TheBlackBenzKid очень любопытно, где вы закончили год спустя, вы сбросили пурпурный?