Magento 1: améliorer mon workflow de développement de module (Modman, composer, git)

C'est quelque chose que j'ai en tête depuis un certain temps, mais je ne trouve pas la bonne méthode pour le faire.

Donc, fondamentalement, je travaille avec 6 sites Web différents, tous exécutant Magento CE 1.9.2+

Sur ces sites Web, j'utilise un tas d'extensions que moi et l'équipe avec lesquelles j'ai travaillé ont développées (ici, nous parlons de plus de 50 extensions) et le code de ces extensions est stocké sur Bitbucket. Je ne suis donc pas la seule personne à gérer ces extensions, nous sommes 3 personnes à y travailler.

En ce moment, quand je veux ajouter une fonctionnalité / corriger un bug pour l'une de ces extensions, voici mon workflow:

• Installez la dernière version de l'extension sur l'un des sites via Modman
• Correction du bug / ajout d'une fonctionnalité / test
• Copiez manuellement les modifications dans un dossier local qui contient toutes mes extensions
• Validez et envoyez via GIT depuis ce dossier d'extension vers Bitbucket (1 dépôt Bitbucket par module)
• Ensuite, la nouvelle version du module peut être installée via Modman

Remarque importante: j'utilise ici modman avec copie papier, pas de lien symbolique.

Mon plus gros problème a été mis en évidence en gras: je veux pouvoir sauter cette étape car c'est une grosse cause de problèmes (certains fichiers sont parfois oubliés, un copier / coller incorrect, implique une action humaine).

Alors, comment puis-je améliorer mon flux de travail afin de me débarrasser de cette étape manuelle de copier / coller? Je suis ouvert aux suggestions ici.

Je prends très souvent l'approche suivante qui est assez indépendante du cadre.

1. Découvrez le module que vous souhaitez modifier /path/to/my/module
2. Créez une branche pour votre travail (dérivée de la balise appropriée, etc.).
3. Engagez le travail dans cette branche (ne poussez pas).

4. Dans votre projet, définissez un référentiel local sur votre copie locale du module. Cela permet à votre projet d'extraire des modifications non poussées de votre LFS.

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

5. Vous pouvez ensuite composer pour exiger votre branche de développement spécifique (si longtemps que vos projets le minimum-stabilitypermettent).

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

6. Vous vous engagez dans /path/to/my/module, composer update namespace/moduledans le projet, voyez-le installer et tester.

7. Lorsque vous avez terminé, écrasez vos commits et poussez.

Je trouve que cette approche fonctionne bien pour les modules M1 en utilisant https://github.com/Cotya/magento-composer-installer , car l'installation avec lien symbolique peut parfois être pénible et vous trébucher lorsque vous ajoutez de nouveaux répertoires ou chemins qui n'étaient auparavant pas liés par un lien symbolique par modman.

Liens susceptibles d'intéresser

• 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

Débogage

1. Utilisez composer require namespace/module dev-branch-name-here -vvvpour voir les branches que vous pouvez utiliser localement.

2. Vérifiez que le projet dans lequel vous installez le module minimum-stabilitya été défini dev.

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

Trouvé en lisant le commentaire de Patrick Schwisow ici .

Si d'autres packages ont des exigences sur le package que vous modifiez, votre branche de développement peut ne pas répondre à ces exigences (ce qui entraînera «Vos exigences n'ont pas pu être résolues en un ensemble de packages installables».). Pour résoudre ce problème, vous pouvez créer un alias en ligne pour que tous les autres packages le voient comme une version spécifique.

En bref, vous pouvez mettre composer.jsonà jour votre pour le forcer à une version spécifique lors du développement, le faire lire comme:

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

J'utilise modman avec copie papier ici, pas de lien symbolique.

Voilà votre problème. Si vous ne pouvez pas modifier cette configuration pour les déploiements de votre boutique, envisagez de travailler sur des extensions partagées sur une instance distincte où vous utilisez modman avec des liens symboliques.

J'utilise compositeur avec le programme d' installation du compositeur AOE pour cloner directement les dépôts d'extension dans .modmanmais l' installation de modules de Git avec des œuvres Modman aussi je suppose. Dans les deux cas, vous pouvez travailler directement dans le référentiel du module Git.

Donc, mon idée ici pour vous est de commencer à travailler avec le compositeur même pour Magento1. Si vous aviez votre propre packagist , ce qui n'est pas trop difficile à gérer maintenant que aws et google cloud sont en place, ou vous pouvez utiliser le packagist public. Vous auriez un accès "facile" aux nouvelles versions dans vos boutiques Magento1.

Cela signifie que lorsqu'une version plus récente sort, vous pouvez composer updateet cela automatisera le processus de copie pour vous.

Jetez un œil à https://github.com/Cotya/magento-composer-installer pour Magento1 via composer.

Avec cette approche, vous pouvez également travailler directement sur le référentiel git sous le dossier du fournisseur si vous l'avez configuré pour copier dans le .gitet ainsi vous pouvez repousser les modifications vers leur référentiel sans avoir une extraction séparée. Cependant, notez que vous devez être prudent ici et vous assurer de savoir sur quelle branche vous vous trouvez, sinon vous pouvez supprimer votre code (cela a été fait plusieurs fois).