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

14

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.

Raphael chez Digital Pianism
la source
avez-vous essayé la Submodulesfonctionnalité de git?
Gopal Patel
Pourquoi utilisez-vous la copie papier? Avec les liens symboliques, vous devriez juste avoir un clone git sous le dossier modman. Ensuite, modifiez simplement en place et appuyez simplement sur.
Kristof à Fooman le
@KristofatFooman J'aurais dû clarifier cela. L'un des développeurs exécute Windows et nous avons donc eu des problèmes avec les liens symboliques ^^
Raphael au Digital Pianism
1
@RaphaelatDigitalPianism pour le problème Windows essayez de regarder github.com/sitewards/modman-php
David Manners

Réponses:

8

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

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"
Luke Rodgers
la source
Une autre approche intéressante ici. Merci pour votre contribution
Raphael au Digital Pianism
1
C'est une bonne. J'ai tendance à utiliser pathdes dépôts de type pour les modules de projet que je ne réutiliserai pas, puis git ou packagist pour les modules que je réutiliserai.
David Manners
1
@DavidManners J'utilise ce flux ci-dessus en combinaison avec satis. Les modules sont en permanence dans satis, mais je ne veux rien pousser dans la ligne principale avant d'avoir testé et exécuté localement. Il s'agit donc d'utiliser le flux de travail ci-dessus, puis de pousser et d'étiqueter et d'attendre que satis le ramasse.
Luke Rodgers
@LukeRodgers, avec ce workflow, vous n'utilisez pas du tout modman et tous vos fichiers de module sont placés dans des fichiers magento? (vous n'avez pas de dossier .modman pour vos extensions). L'ai-je bien compris?
MployBy
Hé @MployBy, je n'utilise pas directement modman. Cependant, je ne sais pas si Cotya / magento-composer-installer l'utilise sous le capot, cela fait un moment que je n'ai pas installé un nouveau module magento1.
Luke Rodgers
6

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.

Fabian Schmengler
la source
Oui, comme je l'ai dit dans les commentaires, la raison en est que l'un des développeurs utilise Windows et IIRC nous avons eu des problèmes avec lui en utilisant des liens symboliques
Raphael à Digital Pianism
6
Oh, je n'ai pas vu ça. Donnez à ce développeur une VM :)
Fabian Schmengler
4

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).

David Manners
la source