Proceso de implementación de Magento 2

Actualmente nos comprometemos composer.lockcon el repositorio y luego lo ejecutamos composer install --no-deven el servidor de producción. No creo que esta sea la mejor manera de hacerlo porque el compositor tarda unos minutos en generar todos los archivos y es arriesgado.

Me pregunto si es mejor comprometerse con el repositorio de todos los archivos necesarios para ejecutarse en modo de producción.

¿Cómo gestionan los demás el proceso de implementación con magento 2?

Acuerde 100% con claudiu-creanga en no comprometer al proveedor y también evitar ejecutar la instalación del compositor en producción.

La forma en que hemos manejado esto es tener una carpeta en vivo y una carpeta de candidato a la versión. Es en la carpeta de la versión candidata donde ejecutamos los comandos git pull y la instalación del compositor --no-dev. Nuestro proceso puede resumirse así:

1. En la carpeta de lanzamiento-candidato:

   • Verificar cambios inesperados
   • Actualizar repositorio
   • Instalación del compositor

2. Sincronizar archivos a la carpeta del sitio en vivo

3. En la carpeta del sitio en vivo:
   • Implementar archivos estáticos
   • Habilitar modo de mantenimiento
   • Habilitar módulos
   • Ejecute scripts de configuración
   • Compilar DI
   • Limpiar cache
   • Deshabilitar modo de mantenimiento
   • Actualizar permisos

He escrito un artículo de blog más extenso dando los comandos y el razonamiento reales detrás de esto: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

ACTUALIZACIÓN: ahora copiamos la base de datos en vivo a una base de datos provisional y la usamos para ejecutar scripts de configuración, implementar archivos estáticos y compilar DI todo sin conexión. Esto se puede implementar en vivo, incluidos los archivos pub / static y var. Todavía eliminamos brevemente el sitio si se están ejecutando los scripts de configuración, pero de lo contrario el sitio se deja arriba. Más detalles en https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/

ACTUALIZACIÓN: he cambiado de opinión sobre la confirmación de la carpeta del proveedor: al confirmar la carpeta, puede realizar un seguimiento del historial de cómo cambian estos archivos, ver si ha cambiado algo accidentalmente y, lo más importante, evita tener que ejecutar el compositor en el momento del despliegue. Esto último es vital ahora que confiamos en proveedores externos de repositorios. ¿Qué pasa si uno de ellos no está disponible? De repente no puedes desplegar. Los inconvenientes son un repositorio más grande, el riesgo de cometer piratas informáticos centrales y la distancia instintiva de desarrolladores como yo :)

Hasta ahora, también confirmamos la carpeta del proveedor, que por supuesto agrega una gran cantidad de archivos a su repositorio. (Asegúrese de eliminar las carpetas .git en los archivos del compositor del proveedor, ya que de lo contrario el contenido de las carpetas no se comprometerá, por ejemplo, firegento). Pero el enlace simbólico de la carpeta del proveedor no funciona, editar la ruta en el archivo vendor_path.php tampoco funciona y hasta ahora no hemos tenido tiempo de buscar una solución mejor.

No tenemos un servidor de compilación y no ejecutamos Composer en el servidor, ejecutamos y probamos todas las actualizaciones localmente y las confirmamos. Esto a su vez activa nuestro script de implementación.

Nuestro script de implementación reemplaza el archivo env.php, hace algunas cosas personalizadas y luego también se activa setup:upgradey setup:static-content:deployantes de cambiar el enlace en vivo a la nueva carpeta.

La única carpeta que tenemos es el enlace simbólico pub / media.

Finalmente, optamos por un servicio como deploybot( http://deploybot.com/ ). Puedes usar el capistranoque es gratis. Deploybot crea un contenedor acoplable mientras se ejecuta la instalación del compositor y si el comando se ejecuta correctamente, implementa el código; de lo contrario, no implementará nada, por lo que su entorno de producción estará seguro.

Considero que este es el mejor enfoque porque:

1) los compositores no recomiendan tener la carpeta del proveedor en su repositorio de git por buenas razones:

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Más información: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) Ejecutar composer install in productionsin redes de seguridad es arriesgado , los paquetes podrían estar inactivos (consulte npm), podría encontrarse con problemas de memoria o cualquier error que pudiera estar ocurriendo mientras el compositor genera archivos y tendrá que lidiar con un entorno de producción roto.

También estoy investigando esto, el enfoque que he tomado hasta ahora es:

Bootstrapping del servidor:

1. Configure el proyecto composer --create-project ... --no-deven una srccarpeta (aunque todavía veo un montón de desarrollo cruzado)
2. Configurar la aplicación, compilar archivos estáticos, actualizar db, etc.
3. Establecer todos los permisos correctos

Lo que me proporcionará una tienda de almacenamiento en ejecución desde mi directorio src (pero mi raíz web no apunta allí)

Entonces mi proceso de implementación:

1. Hacer una nueva carpeta de lanzamiento
2. rsync los archivos src en mi lanzamiento (excluyendo el cruft)
3. implementar y descomprimir mis personalizaciones en la parte superior (un puñado de archivos de temas y módulos)
4. instalar cualquier módulo de magento de terceros a través de magento connect
5. apuntar mi servidor webroot a mi nueva versión (con un enlace simbólico)
6. recarga con gracia mi servidor web

Esto me permite mantener el código principal de Magento separado del mío, usar el compositor para mantenerlo actualizado ... ¡y no necesito enviar 39,102! archivos con cada implementación, o ejecute comandos de compositor en el momento de la implementación.

... Ansioso por escuchar otros enfoques o por las mejores prácticas en esto, y también me encanta saber qué archivos son realmente necesarios para la producción y cuáles son dev .. para que pueda mantener mi webroot limpio.

Una vez que termine, tendré un libro de jugadas ansible y algunos comandos de Fabric para organizar la configuración y la implementación, que estoy feliz de compartir.

Espero que ayude