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?

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.

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.