Control de versiones para desarrollo de módulos

Me pregunto si hay buenas convenciones, en lo que respecta al control de versiones, para desarrollar un módulo que esté utilizando tanto en una sola instancia de Magento como para lanzar como módulo comunitario.

Inicialmente, lo que intenté hacer fue usar modman para administrar el módulo fuera de mi repositorio principal de instancias de Magento. Pero eso terminó siendo problemático en múltiples niveles. Tener un único repositorio que puede instalar fácilmente en diferentes entornos o revertir en producción es extremadamente útil, e incluso diría que se ha convertido en una parte necesaria de mi flujo de trabajo.

Lo que estoy haciendo actualmente es desarrollarlo dentro del repositorio de mi sitio, y planeo dividirlo en un repositorio separado pronto. En ese punto, lo que probablemente haré es:

• Construir en mi entorno local dentro de un repositorio de módulo individual usando modman
• Copie los cambios en el repositorio del sitio cuando esté listo para implementar el código

¿Esperando que haya una mejor manera?

Tenemos algunos módulos donde hemos hecho esto y lo que esencialmente hicimos es:

• Configure un repositorio Git para el módulo.
• Implemente este módulo en la base de código del sitio de producción y confirme todo, incluyendo:
  • enlaces blandos creados por modman
  • el directorio .modman que alberga el repositorio de módulos clonados
• Use modman para "desplegarlo" en otras versiones y / o entorno de desarrollo para desarrollo y pruebas.

Hacerlo de esta manera le brinda la flexibilidad que necesita para el desarrollo del módulo, también versiones del código en el sitio único, y si realiza cambios en el módulo en la base de código de sitio único, puede enviarlos directamente al repositorio del módulo desde El repositorio está allí en el directorio .modman.

ACTUALIZACIÓN: Cuando originalmente escribí esto, no pude tener en cuenta en mi respuesta que Git no permite que los (sub) módulos se comprometan a un repositorio, en cuyo caso "comprometer todo" ¡necesita algo de elaboración!

Por cierto, esto se debe a que lo he hecho más a menudo usando modman para implementar módulos alojados en repositorios de Git en una base de código de producción alojada por SVN ... y Subversion no tiene escrúpulos que eviten que se comprometa todo el árbol de Git al VCS.

Así que aquí va ...

1. Si está utilizando SVN para alojar el código del sitio de producción, no debería tener problemas ya que Subversion no tiene (prácticamente) ningún concepto de submódulos. No le importará

2. Si está utilizando Git para el código del sitio de producción, deberá usar submódulos para "confirmar todo" en el repositorio de código del sitio. Después de usar modman para clonar algo como esto:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   También querrás agregarlo como un submódulo así:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Una vez que haya hecho esto, debería poder agregar el directorio .modman y el archivo .gitmodules al índice y confirmarlo.

   Después de clonar el repositorio que utiliza estos módulos instalados a través de modman, simplemente inicie los submódulos y actualice:

   git submodule init
   git submodule update

PD: Ahora uso Git a tiempo completo en todos los proyectos nuevos, así que espero que este descuido no vuelva a ocurrir. Lo siento chicos. ;)

Parece que la convención actual es proporcionar apoyo para:

• Compositor - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Repositorio de Github

En cuanto a la estructura de directorios, es mínima y preferiblemente el módulo está instalado en el grupo de códigos de la Comunidad.

Una estructura de directorio mínima sugerida sería:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

Opcional / agradable de tener:

• Página de inicio de Github con una descripción, algunas capturas de pantalla y algunas características con viñetas.
• El enlace a una tienda de demostración instalada también sería bueno
• Un resumen de pantalla / dos minutos de su producto

Editar: podría haber entendido mal.

El uso de una combinación de modman / gitignore puede mantener su módulo aislado de su entorno de prueba. Usando la estructura de carpetas anterior, puede permitir explícitamente que solo los archivos de su módulo se confirmen / instalen en su repositorio. En este caso, la respuesta de David es más aplicable. El soporte de Modman para dev / deploy parece ser el consenso.

Aunque todavía no lo he probado, recomendaría usar el compositor para eso.

Versiones incluidas dependencias

Al mantener el composer.lockarchivo en el repositorio, arregla las versiones de todos los módulos y siempre puede restaurar una versión específica (una rama, etiqueta o una versión anterior) utilizando su VCS ( git checkout, svn ..) y luego composer.phar install.

Inconvenientes

Un problema que surge es que su implementación puede depender fácilmente de múltiples fuentes (por ejemplo, GitHub) creando múltiples puntos de falla.

Por lo tanto, necesitaríamos algún tipo de caché o proxy que almacene esos módulos para que siempre podamos implementar.

Satis parece ser capaz de cumplir este propósito (consulte https://github.com/researchgate/broker ) y mi pregunta /programming//q/16211671/288568

Kalen

Tal vez no entendí bien su flujo de trabajo, pero parecía que se estaba desarrollando en un repositorio de magento localmente, luego se separó en un repositorio de modman. ¿Por qué no editar el ./modman/modulesname/CONTENTS en su IDE y enviar el código al repositorio del módulo de forma independiente en el mismo flujo de trabajo que utiliza para desarrollar? puede usar modman para la implementación en producción, puede interactuar con el repositorio individual en la carpeta .modman / modulesname / desde cli o agregando una fuente de versiones a su IDE, aunque realmente use .basedir para mantener sus rutas vinculadas al repositorio fuera de su webroot va a jugar mejor.

También hay una característica realmente agradable de modman que muchas personas no parecen usar. El script bash interpreta un archivo .basedir en el repositorio .modman, si el archivo no existe modman aplica las reglas de enlace simbólico en el archivo modman al mismo nivel que la carpeta .modman ... si el archivo .basedir existe, el el contenido describe una subcarpeta que es el nivel superior de su código de Magento uno abajo de la ruta .modman ... en otras palabras, podría ejecutar (y lo hago) todas las versiones básicas de Magento en carpetas como 'BaseMagento1.9.1.0' 'BaseMagento1.14.2.0' y modman inician la carpeta que contiene estos. Agregue un archivo .basedir a la ruta .modman y podrá cambiar el contenido fácilmente. Esto funciona bien para las pruebas de versión.