Magento2 - implementación local / puesta en escena / producción y gitignore

Este podría ser un tipo de discusión más que una pregunta.

Me gustaría saber qué política de despliegue sigue con Magento2 y locales > puesta en escena > producción ambientes

Después de algunos intentos, hemos decidido que el mejor enfoque (o al menos el más sólido) sería este archivo gitignore, incluida la carpeta del proveedor en git.

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

Por lo tanto, ejecutamos Composer solo en un entorno local: como cualquier extensión nueva o actualización de software se prueba en local, luego se valida y se confirma. Probablemente incluiríamos el archivo app / etc / config.php en git también, pero ese archivo se reescribe cuando se ejecuta setup:upgrade, ¿verdad?

La inclusión del proveedor significa que el tamaño del repositorio será mayor que (tal vez) recomendado, pero de esta manera al implementar el código, simplemente ejecutamos la secuencia:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

Información relacionada: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Vea por qué elegimos el comando de compilación como Magento 2 opcional - setup: di: compile ?

ACTUALIZAR

La verdad es que estamos teniendo algunos problemas al implementar cambios de código en nuestros proyectos publicados de Magento 2

Los cambios funcionan en local y en etapas (marcado en ambos modos: desarrollador y producción ... aunque configuramos conceptualmente esos entornos en modo desarrollador), pero algunos de ellos no funcionan en el entorno de producción (en modo de producción), etc. así que no estoy seguro de que estemos siguiendo la estrategia correcta. Me gustaría ver cuál es la secuencia de comandos apropiada y la relevancia del orden en esos comandos

De hecho, todos los días estoy menos convencido de la utilidad del modo de producción de Magento 2, a menos que no vaya a cambiar nada en el proyecto. ¿Puedes cambiar de opinión?

magento2 git deployment Raúl Sánchez
fuente

Voy por la misma ruta: todo en mi repositorio de git. La máquina de producción no tiene compositor, así que no hay otra manera para mí. ¿Puedo preguntar cómo maneja los repositorios .git dentro de la carpeta del proveedor? Cuando me comprometo con mi repositorio, estos se consideran submódulos y, por lo tanto, no terminan dentro de mi repositorio.

omsta

Respuestas:

De hecho, todos los días estoy menos convencido de la utilidad del modo de producción de Magento 2, a menos que no vaya a cambiar nada en el proyecto. ¿Puedes cambiar de opinión?

No estoy seguro si entiendo lo correcto, pero para eso es exactamente el modo de producción : sistemas de producción donde no cambias nada (en cuanto al código). Hasta el próximo despliegue, eso es.

Creo que la implementación basada en Git que está utilizando es menos adecuada para Magento 2 que para Magento 1, debido a todo el preprocesamiento. La compilación y la implementación son más complejas y, en mi humilde opinión, no hay forma de evitar un proceso de compilación automatizado

Lo que recomendaría:

Tenga implementaciones repetibles , es decir, debe asegurarse de que exactamente el mismo código termine en la producción que estaba en la fase de preparación, incluidos los archivos generados .
Para lograr eso, separe la compilación de la implementación y haga lo siguiente en el proceso de compilación:
- composer install( vendortambién es posible agregar al repositorio, pero si lo hizo solo para evitar ejecutar composer en el servidor durante la implementación, hágalo en el paso de compilación y solo manténgalo composer.locken el repositorio)
- Generación de código (YMMV):
```
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
```
- crear un archivo (la acumulación de artefactos ) desde el directorio completo de Magento, excluyendo mediae var, pero incluyendo vendor, pub, var/generatedy var/di. Comenzando con magento-2.2 , var/generatedy var/dise mueven a generated/codey generated/metadata, lo que hace que sea más fácil separarlos del resto de los varcuales deben ignorarse para las implementaciones.
En la implementación, copie el artefacto de compilación en el servidor de destino, extráigalo a un nuevo directorio y:
- directorios de enlaces persistentes en él ( media, var/session, var/log, ...)
- habilitar el modo de mantenimiento
- cambiar la raíz del documento (generalmente el docroot es un enlace simbólico a la última versión, cámbielo a la nueva versión)
- vaciar caché
- correr setup:upgrade
- desactivar el modo de mantenimiento
Este proceso de implementación se puede implementar fácilmente con Deployer , que es como Capistrano pero en PHP. Puede encontrar una solución de implementación completa para Magento 2 basada en el implementador aquí: https://github.com/mwr/magedeploy2 (¡gracias a netz98!) Y aquí hay otra que usamos: https://github.com/staempfli / magento2-implementación-herramienta
Mantenerse app/etc/config.phpen el repositorio es bueno para realizar un seguimiento de los módulos habilitados y deshabilitados.

Esta no es una instrucción paso a paso, pero debería darle una visión general de una alternativa más sólida a su proceso actual. Eche un vistazo a las herramientas vinculadas para ver cómo puede ser una solución completa.

Fabian Schmengler
fuente

Muchas gracias Fabian ... Estaba buscando algo como esto, ya que he estado usando Capistrano en Magento 1 y esperaba encontrar una herramienta similar para Magento 2 ... Lo intentaré durante la semana y te daré más comentarios

Raul Sanchez

@ fabian-schmengler explica más o menos lo que hacemos. Generamos todo en el entorno de ensayo y lo probamos allí en modo de producción, luego movemos el código generado del entorno de ensayo al entorno de producción para asegurarnos de que el código que termina en el entorno de producción sea exactamente el mismo que tenemos en el ensayo.

diazwatson

Gracias por la explicación. Sería bueno tener el contenido del archivo gitignore en su respuesta.

Mehdi

@Mehdi el .gitignorearchivo no es relevante para el problema real. Puedes usar el predeterminado.

Fabian Schmengler

@FabianSchmengler, tengo un problema similar, todos los cambios de confirmación de archivo se reflejarán después de cada implementación en todos los sistemas, pero la configuración de configuración de administrador que cualquier configuración de tema no reflejará, ¿hay alguna solución para evitar configurar la misma configuración varias veces en todo el sistema?

Jafar pinjar

En mi opinión, espere Magento 2.2 o intente implementar un enfoque similar.

Magento 2.2 introduce la implementación de canalización al separar, por ejemplo, el servidor de compilación con el servidor de producción.

Aquí está la documentación oficial: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Además, actualmente estoy usando Ansible para administrar una implementación automatizada con plantillas de configuración y configuración de entornos múltiples.

Franck Garnier
fuente