Contrôle de version pour le développement de modules

Je me demande s'il existe de bonnes conventions, en ce qui concerne le contrôle de version, pour développer un module que vous utilisez à la fois dans une seule instance de Magento et que vous souhaitez également publier en tant que module de communauté.

Au départ, ce que j'ai essayé de faire était d'utiliser modman pour gérer le module en dehors de mon référentiel d'instance Magento principal. Mais cela a fini par être problématique à plusieurs niveaux. Avoir un référentiel unique que vous pouvez facilement installer dans différents environnements ou restaurer en production est extrêmement utile, et je dirais même que c'est devenu une partie nécessaire de mon flux de travail.

Ce que je fais actuellement, c'est le développer dans le référentiel de mon site, et je prévois de le séparer bientôt dans un référentiel séparé. À ce stade, ce que je ferai probablement, c'est:

• Construire dans mon environnement local au sein d'un référentiel de modules individuel à l'aide de modman
• Copiez les modifications dans le référentiel du site lorsque je suis prêt à déployer le code

En espérant qu'il existe une meilleure façon?

Nous avons quelques modules où nous l'avons fait et ce que nous avons essentiellement fait est:

• Configurez un dépôt Git pour le module.
• Déployez ce module dans la base de code du site de production et engagez tout, y compris:
  • liens logiciels créés par modman
  • le répertoire .modman qui héberge le référentiel de module cloné
• Utilisez modman pour le "déployer" dans d'autres versions et / ou un environnement de développement pour le développement et les tests.

En procédant de cette façon, vous obtenez la flexibilité dont vous avez besoin pour le développement de modules, vous versionnez également le code sur le site unique, et si vous apportez des modifications au module dans la base de code d'un site unique, vous pouvez les remettre directement dans le référentiel du module depuis le dépôt est là dans le répertoire .modman.

MISE À JOUR: Lorsque j'ai écrit cela à l'origine, je n'ai pas pris en compte dans ma réponse que Git n'autorise pas les (sous-) modules à être validés dans un référentiel, auquel cas "commettre le tout" a besoin d'une élaboration!

Soit dit en passant, c'est parce que je l'ai fait plus souvent en utilisant modman pour déployer des modules hébergés dans les dépôts Git dans une base de code de production hébergée par SVN ... et Subversion n'a aucun scrupule l'empêchant de valider la totalité de l'arborescence Git sur le VCS.

Alors voilà…

1. Si vous utilisez SVN pour héberger le code du site de production, vous ne devriez avoir aucun problème car Subversion n'a (pratiquement) aucun concept de sous-modules. Cela ne me dérangera pas.

2. Si vous utilisez Git pour le code du site de production, vous devrez utiliser des sous-modules pour "tout valider" dans le référentiel de code du site. Après avoir utilisé modman pour cloner quelque chose comme ceci:

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

   Vous voudrez également l'ajouter en tant que sous-module comme ceci:

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

   Une fois cela fait, vous devriez pouvoir ajouter le répertoire .modman et le fichier .gitmodules à l'index et le valider.

   Après avoir cloné le référentiel qui utilise ces modules installés via modman, lancez simplement les sous-modules et mettez à jour:

   git submodule init
   git submodule update

PS J'utilise maintenant Git à plein temps sur tous les nouveaux projets, donc j'espère que cette erreur ne se reproduira plus. Désolé les gars. ;)

Il semble que la convention actuelle vise à soutenir:

• Compositeur - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Github repo

En ce qui concerne la structure du répertoire, elle est minimale et de préférence le module est installé dans le pool de code communautaire.

Une structure de répertoire suggérée au strict minimum serait:

.
└── 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

Facultatif / sympathique:

• Page de destination Github avec une description, des captures d'écran et des fonctionnalités à puces.
• Un lien vers une boutique de démonstration installée serait également bien
• Un screencast / aperçu de deux minutes de votre produit

Edit: j'ai peut-être mal compris.

L'utilisation d'une combinaison de modman / gitignore peut garder votre module insulaire de votre environnement de test. En utilisant la structure de dossiers ci-dessus, vous pouvez explicitement autoriser uniquement les fichiers de votre module à être validés / installés dans votre référentiel. Dans ce cas, la réponse de David est plus applicable. Le support de Modman pour dev / deploy semble être le consensus.

Même sans l'avoir essayé moi-même, je recommanderais d'utiliser composer pour cela.

Versioning, y compris les dépendances

En conservant le composer.lockfichier dans le référentiel, vous corrigez les versions de tous les modules et pouvez toujours restaurer une version spécifique (une branche, une balise ou une version plus ancienne) en utilisant votre VCS ( git checkout, svn ..), puis composer.phar install.

Désavantages

Un problème qui se pose est que votre déploiement peut facilement dépendre de plusieurs sources (par exemple GitHub) créant plusieurs points de défaillance.

Nous aurions donc besoin d'une sorte de cache ou de proxy qui stocke ces modules afin que nous puissions toujours nous déployer.

Satis semble être en mesure de servir cet objectif (voir https://github.com/researchgate/broker ) et ma question /programming//q/16211671/288568

Kalen,

Peut-être que je n'ai pas bien compris votre flux de travail, mais il semblait que vous développiez localement un référentiel magento, puis que vous vous sépariez en un référentiel modman. Pourquoi ne pas simplement éditer le ./modman/modulesname/CONTENTS dans votre IDE et pousser le code vers le référentiel de module indépendamment dans le même flux de travail que vous utilisez pour développer. vous pouvez utiliser modman pour le déploiement en production, vous pouvez interagir avec le référentiel individuel dans le dossier .modman / modulesname / de cli ou en ajoutant une source de version à votre IDE, bien qu'en utilisant vraiment .basedir pour garder vos chemins liés au référentiel hors de votre webroot va mieux jouer.

Il y a aussi une fonctionnalité vraiment sympa de modman que beaucoup de gens ne semblent pas utiliser. Le script bash interprète un fichier .basedir dans le référentiel .modman, si le fichier n'existe pas, modman applique les règles du lien symbolique dans le fichier modman au même niveau que le dossier .modman ... si le fichier .basedir existe, le le contenu décrit un sous-dossier qui est le niveau supérieur de votre code Magento un en bas du chemin .modman ... en d'autres termes, vous pouvez exécuter (et je fais) toutes les versions de base de Magento dans des dossiers comme 'BaseMagento1.9.1.0' 'BaseMagento1.14.2.0' et modman lancent le dossier les contenant. Ajoutez un fichier .basedir dans le chemin .modman et vous pouvez facilement changer le contenu. Cela fonctionne bien pour les tests de version.