Magento 2 como requisito de desarrollo del compositor para extensiones


8

Al escribir una extensión, ¿tendría sentido agregar magento/project-community-editiona la require-devsección de composer.json?

La idea detrás de eso es que solo requeriría una composer installpara activar una instalación completa de Magento para el desarrollo o CI.

Para configurar la base de datos, agregaría un script posterior a la instalación con bin/magento setup:install.

Para usar las herramientas de prueba, deberías copiar las secciones autoload-devy require-devdesde magento/project-community-editionporque solo se usan desde la raíz, no desde los requisitos.

Una desventaja que veo es que tendrías que cambiar la versión requerida para probar en más de dos versiones diferentes (dos porque puedes especificar un rango e instalar una vez --prefer-lowest), pero eso es relativamente fácil de solucionar.

¿Algo más que deba tener en cuenta?

Respuestas:


4

La respuesta depende de cuáles sean sus necesidades de CI.

Para las pruebas unitarias, actualmente estoy buscando el enfoque para incluir solo en la sección de requisitos los módulos de Magento reales que tengo como dependencia directa (que obtengo casi todos los módulos de esta manera de todos modos es para que Magento los resuelva):

"require": {
  "magento/module-backend": "~100.0.2",
  "magento/module-sales": "~100.0.2"
}

Esto funciona bien para una de mis extensiones, vea Travis aquí, pero se encuentra con un problema interesante en otra extensión donde Magento debería generar automáticamente una interfaz para un simulacro - detalles aquí.

Si está mirando más allá de las pruebas unitarias, creo que tiene sentido tener un entorno Magento preconstruido en el que instale la extensión en lugar de ejecutar un script de instalación para el entorno Magento en cada compilación.


1

Parece razonable 2 puntos a tener en cuenta:

  1. La instalación a través del compositor lleva bastante tiempo
  2. Cuando tiene un montón de módulos, es bastante incómodo soportar / manejar el procedimiento de instalación dentro de CI con scripts que son únicos para cada módulo. Cuando necesite modificar algo aquí, deberá cambiar todas las extensiones que tenga.

Una de las formas de evitarlo podría ser mantener todo lo relacionado con la compilación en CI en un repositorio separado e incluirlo en módulos como subrepositorios.


Publicado en nombre de Peter Samoilov de aheadWorks ya que no está en StackExchange. :)


1

Tiene sentido incluir solo los módulos de Magento que requiere su módulo:

  • Está claro para todos los que lo instalen, de lo que depende, toda la edición de la comunidad es demasiado amplia.
  • Probablemente quiera probarlo unitariamente (y algunas pruebas de integración), por lo que no necesita una tienda virtual que funcione.
  • Las pruebas funcionales se pueden crear en el repositorio principal de su tienda web, ya que tiene más sentido usar una interfaz y también depender de todo el marco como cosas interconectadas.

Básicamente, su módulo en sí no depende de toda la edición de la comunidad, solo depende de una parte, por lo que eso es lo que debe especificar. De esta manera, aún puede probarlo, pero también tenga claro cuáles son las dependencias.


0

Tampoco estoy seguro de esto. Mi primer enfoque será instalar magento2 desde una imagen acoplable para ejecutar todas las pruebas.

Esto le dará una prueba de funcionamiento en muy poco tiempo, pero creo que debe crear una configuración más específica de compilación que instalar todo a través de Composer.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.