how - ¿Una ruta más rápida para implementar contenido estático en Magento 2? Dev to Live, etc.?

magento 2.2 6 php version

Question

Este es mi entorno. Tenga en cuenta que esto también se establece en los modos de desarrollo y modos de producción relevantes.

Dev:
https://ar.dev.loc/
https://en.dev.loc/
Live:
https://ar.site.com/
https://en.site.com/

Estoy usando una configuración de varias tiendas con árabe e inglés y todo está funcionando bien, incluidos los módulos de construcción y la creación de plantillas.

Sin embargo, si realizo un cambio en cualquier archivo o archivo JS (a pesar de usar menos o menos), tengo que ejecutar los siguientes comandos en mi entorno de desarrollo todo solo para verlos en mi máquina local.

$ rm -rf var/cache var/page_cache var/view_preprocessed pub/static
$ mkdir pub/static
$ bin/magento setup:static-content:deploy
$ bin/magento setup:static-content:deploy ar_SA
$ grunt exec less // sometimes I leave this do this
$ grunt // I swap between these

Esto toma mucho tiempo para hacer este proceso cada vez. Es frustrante ya que soy un programador rápido y me gusta ver CSS y Less inmediatamente en el sitio y no esperar.

El enfoque rápido de lo que nuestro equipo está haciendo es en realidad hacer cambios en pub/static y luego los enviamos a less y app/design etc. y luego hacemos el proceso anterior y luego git.

El servidor en vivo es más o menos lo mismo. Git pull y luego modo de mantenimiento (locura en un sitio ecom en vivo! ¿Quién construye M2? Luego ejecutamos los comandos anteriores - tiempo de inactividad de 45 minutos)

Seguramente debe haber una forma más rápida para que nuestra implementación, desarrollo y equipo funcionen mejor y para ver los cambios más rápido sin tiempo de inactividad.

Incluso la documentación oficial de Magento 2 dice que su sitio LIVE debe entrar en modo de mantenimiento y tiempo de inactividad para publicar contenido; esta no es una opción para nosotros. El CTO no está contento. Simplemente absurdo.

Preguntas relacionadas con personas que preguntan sobre el mismo problema de desarrollo más rápido:

Los cambios de CSS se reflejan solo después de implementar el comando en magento2

Caché estática Magento 2

Los cambios en CSS y JavaScript solo se aplican después de implementar contenido estático

Entonces quiero cotejar todos los problemas y resolver esto.

Answer 1

Comentario general:

No debe hacer "gruñidos" aquí mientras hace la configuración: static-content: deploy. Puede generar el contenido estático para en_US (es decir, sin el parámetro) y ar_SA en paralelo (bash le permite hacerlo con bastante facilidad).

Si omite recursos HTTPS (seguros) (tal vez esa fue la razón por la que usó ronco adicionalmente), asegúrese de que la variable de entorno "HTTPS" esté configurada (por ejemplo, HTTPS=ON ) para el proceso que compila contenido estático ( ref ).

Aparte de eso, sí lleva tiempo. Lo que ha llamado la atención es que la compilación menos PHP lleva bastante tiempo. Una idea que se me vino a la mente cuando me enteré de eso por parte de otro desarrollador fue almacenar en caché menos compilación en un caché local menos y solo volver a compilar si un archivo realmente cambia. Quizás puedas probar eso también.

Todavía no soy responsable de hackear un PoC juntos, pero creo que debería ser una buena prueba para la afirmación de que cuanto menos compilación es el cuello de botella.

También puedo sugerir que ejecute un servidor de compilación que compila git push automáticamente para reducir la carga.

Answer 2

Como (--jobs) opción -j (--jobs) para bifurcar un nuevo proceso, reduzco el static-content:deploy tiempo de más de 10 minutos a menos de un minuto. Ver Magento/Deploy/Process/Queue.php

php bin/magento setup:static-content:deploy -j[JOBS_AMOUNT]

--jobs opción --jobs habilita el procesamiento paralelo usando el número especificado de trabajos. El valor predeterminado es 4. Para hacer que la tarea se ejecute en un proceso (por ejemplo, si su sistema no es compatible con el proceso de bifurcación), use --jobs 1 . // ver: devdocs.magento.com

Esta opción solo se puede usar si pcntl está habilitado.

pcntl

No se necesitan bibliotecas externas para construir esta extensión.

El soporte de Control de procesos en PHP no está habilitado por defecto.

Debe compilar la versión CGI o CLI de PHP con la opción de configuración --enable-pcntl al compilar PHP para habilitar la compatibilidad con Process Control.

Nota: Actualmente, este módulo no funcionará en plataformas que no sean Unix (Windows).

Nota: ¡ que pcntl_fork no funcionará si PHP se está ejecutando como un módulo de Apache, en cuyo caso esta función no existirá!

Answer 3

En nuestra empresa administramos implementaciones de Magento2 utilizando Capistrano , también hay un conjunto de tareas específicas para Magento 2 que funciona muy bien.

Con capistrano, configura la raíz de su servidor web para que apunte a un enlace simbólico que apunta a una carpeta de "lanzamiento". Cuando inicia una implementación, toda la compilación (di, contenido estático, ecc) se realiza en una carpeta separada para que su sitio web en línea no se vea afectado y permanezca en línea. Al final del procedimiento, y solo si no hay errores, el enlace simbólico cambia a la nueva versión.

De esta forma, el tiempo de inactividad suele ser cero o reducido a un par de segundos.

Capistrano también proporciona una característica básica de "reversión" que permite volver rápidamente a una versión anterior si algo sale mal.

Answer 4

He venido con una solución para este problema.

Tienes que publicar el contenido de la tienda que deseas por

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

No cambiaré porque magento cache, así que simplemente elimínelo manualmente

rm -rf pub/static/_*/*
php bin/magento cache:flush; php bin/magento cache:clean;

La actualización de su página y hecho ahora requiere nuevos cambios cuando se regenera de página.

Estos pasos son obligatorios para los cambios en contenido phtml y estático, los cambios en el diseño requieren el vaciado de caché y los cambios en los controladores son un problema difícil porque necesita usar di: compilar este realmente lo hace salir de la producción.

Answer 5

No estoy familiarizado con magneto pero esto puede funcionar para usted. Cuando actualizo mis sitios, sigo esos pasos:

Supongamos que el sitio está ubicado bajo el directorio del site .

$ cp -r site site-update
# update the site in site-update directory
$ mv site site-old && mv site-update site

De esta forma mis sitios se actualizan sin ningún tiempo de inactividad.

Answer 6

No he tocado la setup:static-content:deploy in awhile. Después de estar harto del lento proceso de implementación en Magento 2, ideé el mío que me permite hacer un cambio en un archivo CSS o JS y hacer que se refleje casi de inmediato en el sitio. Aquí está la magia:

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

Vamos a descomponerlo ...

1. cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME - cambie al directorio de temas activos (reemplace $VENDOR y $THEME con sus propios valores)
2. find * -type f /( -name "*.css" -o -name "*.js" /) -cmin -10 - encuentra todos los archivos CSS y JS que fueron cambiados de alguna manera en los últimos 10 minutos dentro del tema directorio ( * se deshace del líder ./ en los resultados); puede cambiar cualquiera de los parámetros para adaptarse a sus necesidades
3. xargs -I {} bash -c - para cada archivo modificado, ejecute los comandos en # 4-6 (la ruta relativa al archivo modificado se almacena en {} )
4. dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web//|//[^/]+$)//g") : configure la ruta de destino de implementación
   • el * glob se encarga de hacer coincidir cualquier localidad en la que estés
   • $(...) genera una subshell para extraer solo la parte de la ruta de origen que necesitamos agregar a la ruta de destino ( web nivel de directorio web no existe en pub )
5. echo Deploying {} to $dest ... - registre la actividad en la consola para que sepa qué archivos se están implementando
6. mkdir -p $dest && cp {} $_ - crea la estructura del directorio de destino; si y solo si la estructura del directorio se creó con éxito, copie el archivo modificado a su destino de implementación en pub ( $_ puntos al último argumento del comando anterior, mkdir , que es $dest )
7. cd - 1> /dev/null - cambia al directorio anterior para que puedas continuar donde lo dejaste

Puede lanzar todo esto en un alias para reducirlo a un comando, pero recuerde escapar de las comillas simples:

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''

Si usa barniz, debe agregar un comando para reiniciar barniz al final del alias (por ejemplo, sudo service varnish restart ) o es probable que todavía esté golpeando activos estáticos almacenados en caché.

Si es demasiado perezoso para escribir la update cada vez que realiza un cambio, puede ponerlo en un cron o integrarlo en una tarea de monitor de grunt o equivalente.

Answer 7

También me he dado cuenta de que si tiene css y js iniciando sesión, parece que se agote si ejecuta la actualización de configuración, luego rompe la versión y se quitan los css / js hasta que se reconstruya el contenido estático.

No tengo idea de cómo creen que esto debería funcionar para las personas en producción. Casi cualquier cosa puede salir de wack y tienes que reconstruir.

He tenido un poco de suerte con 1. activar css / js iniciando sesión en 2. luego puedes ejecutar implementación de contenido estático, parece mantener tu memoria bastante intacta 3. vaciar el caché (luego agrega la nueva versión12312312 a las URL estáticas)

Pero en serio, no hay forma de ser sólido como una roca con las implementaciones.

TheBlackBenzKid, muy curioso, donde terminaste un año después, ¿dejaste magento?

Answer 8

sí, puede ser más rápido siguiendo los pasos:

1. Cambie su archivo js / css en el directorio de la aplicación
2. Ahora borre el archivo de la carpeta pub / static

puedes encontrar el archivo en la barra estática siguiendo el comando

find pub/static -iname yourjsfile.js

3. elimine solo el archivo en el que tiene cambios de la carpeta pub / static
4. asegúrese de que el archivo pub / static.htaccess y el archivo pub / static.php estén allí
5. asignar permisos de escritura de archivo a la carpeta pub
6. ahora pulse la URL en el navegador .htaccess desplegará directamente el archivo js que falta

.htaccess en pub / static envía los archivos faltantes a pub / static.php con el recurso del parámetro y el archivo pub / static.php crea un StaticResource para el archivo si está disponible e implementa eso.

Nota: esto solo funciona con apache mod_rewrite

Para Nginx, necesita configurar lo mismo a través de nginx.conf.sample