Técnicas de implementación de arquitectura de referencia global
Existen varias formas de optimizar la reutilización del código con Adobe Commerce. Estas cuatro técnicas de implementación tienen sus propias ventajas. Los ejemplos de este artículo se ordenan de simples a más complejos. Elija la estrategia que mejor se adapte a su proyecto y a la hoja de ruta futura. La migración de una estrategia a otra puede llevar mucho tiempo.
Cuándo utilizar la arquitectura de referencia global
La arquitectura de referencia global puede ser útil, según el número de instancias que tenga. Una instancia de es una instalación independiente de Adobe Commerce que utiliza su propia base de datos. Haga un recuento de las bases de datos de producción para saber cuántas instancias tiene. Si mantiene más de una instancia de o si prevé este escenario en el futuro, puede beneficiarse de la arquitectura de referencia global. Cuanta más funcionalidad compartan las instancias, más valor añadirá una arquitectura de referencia global.
En cualquiera de estos casos, es aconsejable explorar con varias instancias de Adobe Commerce.
- Diferentes propietarios de tiendas: Si mantiene código para varios propietarios de tiendas, cada uno con su propio almacén, pueden ser necesarias instancias independientes para mantener sus requisitos individuales de forma eficaz.
- Cumplimiento de las regulaciones nacionales: ciertas regulaciones exigen que los datos de los clientes se almacenen dentro de regiones específicas. En tales casos, es esencial contar con instancias separadas para asegurar el cumplimiento de estas regulaciones.
- Desviaciones operativas entre regiones geográficas: Operar en varias regiones puede significar diferentes calendarios y requisitos de mantenimiento. El uso de instancias independientes permite flexibilidad para administrar estas variaciones de forma eficaz.
- Ventas de flash de alta intensidad: Las tiendas que realizan ventas de flash a gran escala a menudo requieren un rendimiento de servidor optimizado. La infraestructura dedicada proporcionada por instancias independientes garantiza un rendimiento óptimo durante estos períodos de alta demanda.
- Diferencias significativas entre marcas o países: cuando la diferencia entre marcas o países es grande, el uso de una sola instancia genera código que solo se utiliza para algunas marcas o países. Las instancias independientes pueden mejorar el rendimiento y la estabilidad al eliminar el código innecesario para las marcas y los países que no lo necesitan.
Patrones de arquitectura de referencia global
Junto a "sin patrón GRA" hay cuatro estilos de patrones GRA.
No hay patrón GRA
Cuando no se utiliza un patrón GRA, cada instancia de Adobe Commerce es una aplicación única. No se puede reutilizar el código, excepto moviéndolo manualmente de una instancia a otra. Estas copias siempre divergen. La cantidad de esfuerzo para garantizar que cada instancia tenga los mismos cambios pero funcione según lo esperado puede ser abrumadora. En esta situación, tres instancias necesitan el triple de esfuerzo de mantenimiento que una instancia.
El patrón Git GRA dividido
Este patrón consiste en repositorios Git para desarrollo y un repositorio Git por instancia. Cada archivo de la instancia se mantiene en uno de los repositorios de desarrollo. Se juntan como una trenza formando todo el GRA. Cada línea de código solo existe en un único repositorio de desarrollo y se instala en las instancias mediante la técnica de entrelazado, lo que provoca la reutilización del código.
El patrón GRA de paquetes masivos
Los módulos principales de Adobe Commerce y de terceros se instalan directamente a través de los repositorios de Composer. Los repositorios Git se pueden usar como repositorios Composer. En este patrón, toda la base de código compartido de GRA se aloja en uno o pocos repositorios Git y se instala a través de Composer. La característica clave es que varios módulos, paquetes de idiomas o temas se alojan en un solo paquete de compositor, lo que simplifica el desarrollo.
El patrón GRA de paquetes separados
Cada módulo, paquete de idioma o tema de Adobe Commerce se instala como un paquete de compositor independiente. Cada personalización tiene su propio repositorio de Git. Esto significa la máxima flexibilidad en la composición de las instancias y dispone de una gestión de dependencias del Compositor fiable. Para optimizar el rendimiento, todos los paquetes se duplican en un único repositorio privado de Composer.
El patrón de monorepo GRA
Todo el desarrollo tiene lugar en un único repositorio de código. La automatización genera paquetes para las nuevas versiones y los publica en un repositorio del compositor. El patrón combina la baja sobrecarga de desarrollo del enfoque de paquetes masivos con la flexibilidad del enfoque de paquetes separados. El patrón monorepo también es ideal para ejecutar pruebas funcionales automatizadas.
Elección de un patrón GRA
La elección de un patrón GRA se realiza mediante la evaluación de la complejidad del proyecto, la necesidad de flexibilidad y la capacidad del equipo de desarrollo para adaptarse.
Los equipos con poca experiencia en Adobe Commerce deberían empezar de forma sencilla. Sin embargo, si el proyecto exige un patrón de GRA más complejo debido a sus características, no comprometa.
Características comunes del proyecto relacionadas con cada patrón:
-
Sin patrón GRA: instancia única de Adobe Commerce sin planes de extensión. Varias instancias de Adobe Commerce con un mínimo de elementos comunes entre ellas.
-
Patrón Split Git GRA: Los equipos que desean evitar Composer para sus personalizaciones, en la mayoría de los casos el patrón Bulk packages es el preferido para Split Git.
-
Patrón GRA de paquete masivo: base de código de personalización con alta interdependencia. Todas las instancias tienen combinaciones muy similares de paquetes personalizados. No hay promociones ni descensos frecuentes de paquetes individuales. Equipos con poca experiencia en gestión de código y con necesidad de simplicidad.
-
Patrón GRA de paquetes independientes: se necesita una administración flexible del ámbito de lanzamiento. Se prevén 50 paquetes personalizados o menos en los próximos 5 años. Capas globales y regionales de código común. No hay planes para migrar a un patrón de Monorepo. El equipo es técnicamente experto y tiene una estricta adherencia al proceso.
-
Patrón GRA de Monorepo: todas las características del patrón GRA de paquetes separados. Se prevén más de 50 paquetes en los próximos 5 años. Necesidad de realizar pruebas automatizadas exhaustivas. Soporte para ambientes efímeros. Base de código complejo a escala empresarial que debe ampliarse sin aumentar el coste de mantenimiento a la misma velocidad.
El coste de una elección incorrecta
La migración de un patrón a otro es posible. El diagrama siguiente muestra el nivel de impacto de pasar de un patrón a otro. Las líneas verdes muestran un bajo impacto, las amarillas y ámbar muestran migraciones de moderadamente complejas a complejas.
