Prácticas recomendadas de administración de código para Adobe Commerce
Este tema se ha diseñado para ayudarle a decidir si desea utilizar Git o Composer para distribuir código personalizado, teniendo en cuenta la gestión de versiones, la complejidad del código y la administración de dependencias.
Productos y versiones afectados
Todas las versiones compatibles de:
- Adobe Commerce en la infraestructura en la nube
- Adobe Commerce local
Definiciones
- Arquitectura de referencia global (GRA): también conocida como Arquitectura de etiquetas blancas o Base de código común. Arquitectura de distribución de módulos para una configuración de varias instancias.
- Configuración de varias instancias: El mismo cliente usa instalaciones de Adobe Commerce independientes para regiones o marcas independientes. Cada instalación tiene módulos compartidos y únicos.
- Configuración de instancia única: solo hay una instalación de Adobe Commerce. Pueden existir varias copias del código fuente para diferentes entornos de prueba, pero solo hay una versión del código de producción.
Cuándo usar Git o Composer
- Enfoque estándar para administrar código para una configuración de instancia única
- Cuando el código base no forme parte de un GRA multimarca en el futuro
- Cuando todas las marcas se ejecutan en una sola instancia como sitios web
- Cuando la base de código pueda formar parte de una configuración de varias instancias en el futuro o pueda hacerlo
- Cuando casi todos los módulos están interrelacionados (no se recomienda)
- Cuando el código lo mantiene un equipo que no está familiarizado con Composer
- Enfoque estándar para administrar código para una configuración de varias instancias
- Cuando el Adobe mantiene el código base o el equipo de mantenimiento está familiarizado con Composer
Matriz de características
Cada paquete Composer individual está representado por un repositorio Git
app/
vendor/
vendor/
si se instalan a través del mercado o packagist.org. De lo contrario, se instalarán en app/
vendor/
git merge
y git pull
o git checkout
comandoscomposer update
y git pull
o git checkout
comandosmodule.xml
, funcionalidad limitada
composer.json
Soluciones que se deben evitar
-
Compositor combinado y
app/code
para sus módulosConsiga que todas las desventajas de ambos estilos de administración de código se combinen en su proyecto. Añade complejidad, inestabilidad y falta de flexibilidad innecesarias.
Por ejemplo:
- Explique los flujos de trabajo de Git y Composer (en lugar de solo uno de ellos) al equipo de desarrollo.
- Instale módulos incompatibles en
app/code
, ya que no hay nada que impida que esto ocurra. - Mover un módulo de
app/code
a Compositor (o a la inversa) es engorroso, especialmente con el desarrollo en curso.
-
Administrador de paquetes Satis
Packagist privado cuesta ± € 600 por año. Este coste es para todo el GRA combinado, no por marca. No trate de evitar estos costos utilizando la solución gratuita Satis. Satis no actualiza automáticamente sus paquetes cada vez que inserta confirmaciones en Git. Además, Satis no tiene una autorización integrada. Debe mantener un servidor web para ejecutar Satis. Usted acaba gastando una multitud de la cuota de suscripción de Packagist privado manteniendo Satis.
-
Empiece con Git y, a continuación, pase a Composer
Elija un método de administración de código al principio del proyecto. Cambiar de Git a Compositor o, a la inversa, con un desarrollo en curso es engorroso y podría provocar la pérdida del código o la pérdida del historial de revisiones.