Magento 1: mejorar el flujo de trabajo de desarrollo de mi módulo (Modman, composer, git)

Esto es algo que he tenido en mente durante bastante tiempo, pero no puedo encontrar el método correcto para hacerlo.

Básicamente, estoy trabajando con 6 sitios web diferentes, todos con Magento CE 1.9.2+

En esos sitios web, estoy usando un montón de extensiones que yo y el equipo con el que estoy trabajando hemos desarrollado (aquí estamos hablando de más de 50 extensiones) y el código para esas extensiones se almacena en Bitbucket. Así que no soy la única persona que administra esas extensiones, somos 3 personas trabajando en ellas.

En este momento, cuando quiero agregar una función / corregir un error para una de esas extensiones, aquí está mi flujo de trabajo:

• Instale la última versión de la extensión en uno de los sitios web a través de Modman
• Solucione el error / agregue una función / prueba
• Copie manualmente los cambios en una carpeta local que contenga todas mis extensiones
• Comprometerse y enviar a través de GIT desde esta carpeta de extensión a Bitbucket (1 repositorio de Bitbucket por módulo)
• Luego, la nueva versión del módulo se puede instalar a través de Modman

Nota importante: estoy usando modman con copia impresa aquí, sin enlace simbólico.

Mi mayor problema se ha resaltado en negrita: quiero poder omitir este paso porque es una gran causa de problemas (a veces se olvidan algunos archivos, copiar / pegar incorrectamente implica acción humana).

Entonces, ¿cómo puedo mejorar mi flujo de trabajo para deshacerme de este paso manual de copiar / pegar? Estoy abierto a sugerencias aquí.

A menudo adopto el siguiente enfoque, que es bastante independiente del marco.

1. Consulte el módulo al que desea editar /path/to/my/module
2. Cree una rama para su trabajo (ramificado de la etiqueta relevante, etc.).
3. Compromete el trabajo con esta rama (no presiones).

4. En su proyecto, defina un repositorio local para su copia local del módulo. Esto es para que su proyecto pueda obtener cambios no apresurados de su LFS.

   {
       "repositories": [
       {
           "type": "path",
           "url": "/path/to/my/module"
       }
   ],

5. Luego, puede crear su rama de desarrollo específica para su compositor (siempre que sus proyectos lo minimum-stabilitypermitan).

   composer require namespace/module dev-branch-name-here

6. Te comprometes /path/to/my/module, composer update namespace/moduleen el proyecto, verlo instalar y probar.

7. Cuando termines, aplasta tus commits y empuja hacia arriba.

Creo que este enfoque funciona bien para los módulos M1 usando https://github.com/Cotya/magento-composer-installer , ya que la instalación con enlaces simbólicos puede ser un problema a veces y te hace tropezar al agregar nuevos directorios o rutas que anteriormente no estaban enlazados. por modman.

Enlaces que pueden interesar

• https://lornajane.net/posts/2014/use-a-github-branch-as-a-composer-dependency
• https://lornajane.net/posts/2015/relying-on-a-dev-master-dependency-in-composer
• https://getcomposer.org/doc/05-repositories.md#path

Depuración

1. Use composer require namespace/module dev-branch-name-here -vvvpara ver las ramas que puede usar localmente.

2. Verifique que minimum-stabilityse haya configurado deven el proyecto en el que está instalando el módulo.

3. Your requirements could not be resolved to an installable set

Encontrado leyendo el comentario de Patrick Schwisow aquí .

Si otros paquetes tienen requisitos en el paquete que está cambiando, es posible que su rama de desarrollo no cumpla con esos requisitos (lo que resultará en "Sus requisitos no se pudieron resolver en un conjunto de paquetes instalables"). Para solucionar esto, puede hacer un alias en línea para que todos los demás paquetes lo vean como una versión específica.

En resumen, puede actualizar su composer.jsonpara forzarlo a una versión específica durante el desarrollo, hacer que se lea como:

"namespace/module": "dev-branch-name-here as 1.2.3"

Estoy usando modman con copia impresa aquí, sin enlace simbólico.

Ahí está tu problema. Si no puede cambiar esta configuración para las implementaciones de su tienda, considere trabajar en extensiones compartidas en una instancia separada donde use modman con enlaces simbólicos.

Utilizo el compositor con el instalador del compositor AOE para clonar los repositorios de extensión directamente, .modmanpero supongo que instalar módulos desde Git con modman también funciona. De cualquier manera, puede trabajar directamente en el repositorio Git del módulo.

Así que mi idea aquí para ti es comenzar a trabajar con el compositor incluso para Magento1. Si tuvieras tu propio packagist , que no es demasiado difícil de administrar ahora que aws y google cloud están en su lugar, o puedes usar packagist público. Tendría acceso "fácil" a versiones más recientes en sus tiendas Magento1.

Esto significa que cuando salga una versión más nueva, puede composer updatey automatizará el proceso de copia por usted.

Echa un vistazo a https://github.com/Cotya/magento-composer-installer para Magento1 a través del compositor.

Con este enfoque, también puede trabajar directamente en el repositorio de git en la carpeta del proveedor si lo tiene configurado para copiar en el .gity, por lo tanto, puede hacer que los cambios vuelvan a sus repositorios sin tener que pagar por separado. Sin embargo, tenga en cuenta que debe tener cuidado aquí y asegurarse de saber en qué rama se encuentra; de lo contrario, puede eliminar su código (hecho varias veces).