Quelle est la structure préférée d'un projet Magento 2 sous VCS?

15

Lorsque je démarre un nouveau projet M2, la première chose que je ferais est d'installer le core via composer:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

Je peux maintenant écrire mes modules et thèmes personnalisés sous app/code. J'ajouterais alors mon composer.*et le app/codedossier entier à mon VCS. Jusqu'à présent, tout va bien.

Supposons maintenant que je veuille utiliser des outils de construction pour mon projet, disons Grunt ou Gulp.

  1. Si je valide le mien Gruntfile.js, ce sera écrasé par le magento/magento2-basepackage lorsque j'exécuterai composer installaprès avoir cloné le dépôt.

  2. Si je valide mon gulpfile.js, je ne peux pas vraiment définir mes dépendances dans a package.json, car il serait également écrasé par magento/magento2-base.

  3. Si je décide d'utiliser la configuration de Magento Grunt et que je souhaite la personnaliser en modifiant les fichiers sous /dev/tools/grunt(par exemple themes.js), je ne peux pas car mes modifications seraient écrasées par magento/magento2-base.

Je crois comprendre que vous ne pouvez pas vraiment faire grand-chose dans la racine de votre document. Il existe bien sûr de nombreuses solutions à ce problème:

  • Je pourrais exécuter un git checkout -droit après l'installation pour réinitialiser mes propres fichiers
  • Je pourrais stocker mes fichiers de construction dans un dossier dédié, /buildpar exemple
  • Je pourrais utiliser un outil de construction différent, comme Phing, Ant ou Rake (mes développeurs frontaux ne seraient pas si heureux cependant)
  • Je pourrais remplacer magento/magento2-basepar un package personnalisé qui a un mappage personnalisé pour les fichiers de base (pas vraiment optimal mais bon, c'est une option)

Personnellement, je n'aime pas toutes ces options, je voudrais donc savoir s'il existe une façon préférée ou meilleure de réaliser ce que j'essaie de faire.

Quelqu'un a-t-il le même problème? Comment l'avez-vous résolu? Comment structurez-vous votre projet sous VCS?

MISE À JOUR

Un point supplémentaire lié à la configuration du projet. Dans mes expériences, j'ai remarqué que le programme d'installation de Magento composer a un indicateur pour remplacer le fichier:

"extra": {
    "magento-force": "override"
}

Il est traité en interne comme un booléen si je ne me trompe pas, j'ai donc essayé de le régler falsepour ignorer la substitution. Lorsque j'exécute, composer installmon installation échoue car le ou les fichiers sont déjà présents. Fondamentalement, si je ne laisse pas Magento remplacer mes fichiers, je ne peux pas l'installer.

Quel est le but de ce drapeau alors? Est-ce seulement supposé effectuer un contrôle pour moi? Pour être honnête, cela n'a pas beaucoup de sens, mais peut-être que quelqu'un peut faire la lumière sur le sujet.

fmrng
la source
Je suis curieux de voir ce que les autres publient comme réponse. Idéalement, je pense que nous voudrions garder Magento Core hors de notre référentiel principal et le limiter au modèle que nous créons et à tous les plugins personnalisés que nous ajoutons ou que nous corrigeons. Ensuite, au moment de la construction, nous référençons le noyau + notre référentiel de projet et construisons un artefact d'application à partir des référentiels. C'est la méthode que j'ai utilisée récemment pour M1 et je me demande si la recommandation officielle de Magento est de faire quelque chose de similaire avec M2 maintenant que Composer est entièrement pris en charge.
Bryan 'BJ' Hoffpauir Jr.
Dans les nouvelles versions M2, le Gruntfile.js, gulpfile.jset package.jsonproblème est résolu. Le problème abordé dans cette question est toujours applicable aux nouvelles versions de Magento 2 lorsque vous devez changer themes.js, index.phpou .htaccesspar exemple.
7ochem

Réponses:

4

À court terme, nous cherchons à séparer les fichiers qui nécessitent une personnalisation. Par exemple, si les gens ont besoin de modifier index.php, découvrez comment séparer le fichier standard livré par Magento du besoin de personnalisations locales. Une fois atteint, il est possible d'avoir "un seul vrai .gitignore pour tous les projets utilisables". Autrement dit, il est facile de valider tout le répertoire du projet dans Git avec .gitignore de tout ce que "installer le compositeur" récupérera pour vous (et tout ce que "la mise à jour du compositeur" remplacera lors de l'installation d'un correctif ou d'une mise à niveau).

A plus long terme, l'objectif est de raccourcir autant que possible le .gitignore. Par exemple, pousser plus dans les modules sous le répertoire «vendeur».

alors

  1. Pour tout ce que vous ne souhaitez pas partager entre projets, laissez-le sous app / code et validé dans le référentiel de projet principal.
  2. Tout ce qui a été développé localement, que vous souhaitez partager plus facilement entre les projets, placez-le dans un référentiel GIT séparé et installez-le via le compositeur pour qu'il finisse sous `` fournisseur ''. (Il peut s'agir d'un dépôt de compositeur local, ou simplement installer directement à partir de GIT.)

De cette façon, vous pouvez toujours git valider la totalité de l'arborescence du projet de haut en bas, capturant les fichiers composer.json et composer.lock (la validation uniquement de l'application / du code ne le fait pas). Le .gitignore exclura le répertoire «vendeur» et les autres fichiers non souhaités.

Cela vous donne le meilleur des deux mondes mentionnés dans l'autre discussion. La difficulté actuelle est la longueur et la complexité du fichier .gitignore, et l'installation des correctifs efface actuellement certaines personnalisations locales (par exemple dans index.php). Solution de contournement à court terme - supprimez index.php de .gitignore, et lorsque vous installez un correctif, vérifiez les modifications que vous avez perdues (git diff) et réappliquez-les manuellement.

Alan Kent
la source
OK, vous allez donc changer certaines choses dans un avenir proche, c'est bien! Je me demande si ce "magento-force": "override"drapeau pourrait être utile d'une manière ou d'une autre. Pour le moment, il ne fait pas exactement ce à quoi je m'attendais. Dans le cas où vous avez modifié / étendu votre index.phpou tout autre fichier "de base", vous pouvez simplement dire à Magento de ne pas écraser vos modifications. Celà a-t-il un sens?
fmrng
3

Il existe une solution simple pour votre problème prioritaire: ne changez pas les fichiers principaux;) Magento est basé sur l'extension du code et non sur sa modification.

La première chose est que vous ne devez pas mettre l'intégralité de votre dossier d'application / de code dans un référentiel vcs. Chaque composant Magento (module, thème, etc ...) devrait être un référentiel lui-même.

Si vous souhaitez modifier / étendre le frontend, vous devez créer un nouveau thème et traiter ce thème comme votre projet de grognement, pas l'ensemble de l'instance Magento2.

Pour installer votre thème dans votre projet, vous pouvez facilement le récupérer via le composeur directement depuis votre référentiel vcs

David Verholen
la source
Eh bien, le app/codedossier est spécifiquement là pour personnaliser Magento. Ma compréhension du M2 actuel est qu'il app/coderemplace ce qui app/code/localétait dans M1, et les modules de communauté peuvent être installés via composer sous vendor. Nous avons quelques projets avec un GRAND nombre de modules et plusieurs thèmes également. Ce que vous proposez serait impossible à gérer.
fmrng
Hé, nous gérons des projets avec> 100 composants de cette façon. La clé est de garder les modules petits et de gérer vos dépendances de compositeur entre les modules. Vous pouvez cloner le référentiel de projet magento pour vos propres besoins et ajouter tous vos composants à votre projet
David Verholen
Si vous êtes satisfait de votre configuration actuelle, tout va bien. Honnêtement, je trouve cela assez lourd. Cela signifie que vous avez plus de 100 référentiels git, et chaque fois que vous modifiez quelque chose, vous devez ouvrir un projet spécifique, valider vos modifications, exécuter composer update. Où engagez-vous votre composer.lockalors? Si plus de 10 développeurs travaillent sur le même projet, cela pourrait s'avérer très compliqué. Bien sûr, nous avons beaucoup de modules généraux (et même de thèmes) que nous installons via Composer, mais le code spécifique au projet doit être versionné sous le même référentiel pour plus de clarté.
fmrng
Je ne dis pas que vous vous trompez, je pense que c'est un peu trop compliqué à mon goût. Par intérêt, comment inspectez-vous l'historique de vos repo avec une telle configuration? Comment pouvez-vous utiliser des fonctionnalités telles que git blameou git loglorsque le code est dispersé dans plusieurs composants? Exécutez-vous des tests d'intégration pour vérifier que tout fonctionne correctement?
fmrng
nous avons eu cette discussion en interne l'année dernière et les déploiements sont devenus assez simples depuis que nous avons décidé d'en faire 1repo = 1module. Le fait est que vous ne feriez pas une mise à jour du compositeur pour un petit changement. Les développeurs travaillent dans des environnements de développement et y modifient directement les fichiers. Quand ils ont terminé, ils peuvent le marquer comme candidat alpha, beta ou release. De cette façon, plusieurs développeurs peuvent travailler sur de nombreux projets en même temps et la prochaine fois, vous effectuez une mise à jour du compositeur, vous tirez toutes les modifications. Il existe d'excellents outils pour organiser vos packages vcs et compositeur.Des centaines de référentiels ne devraient pas être un problème
David Verholen
2

Ok, on dirait que j'ai trouvé une meilleure solution pour ce que j'essayais de réaliser. Dans le composer.json, il est possible de spécifier quels fichiers doivent être ignorés par le programme d'installation de Magento Composer. Si je ne veux pas que mon nom Gruntfile.jssoit remplacé, je peux simplement le spécifier avec la configuration suivante:

"extra": {
    "magento-deploy-ignore": {
        "magento/magento2-base": [
            "/Gruntfile.js",
            "/package.json"
        ]
    }
}

Je suis maintenant en mesure d'étendre l'installation standard pour répondre à mes besoins.

fmrng
la source
Cette solution ne semble pas «sécurisée pour la mise à niveau». Si Magento apportera des modifications à ces fichiers que vous ignorez, alors vous ne le saurez pas ou vous oublierez ces fichiers. Vous utilisez votre propre version qui n'inclura jamais ces nouvelles modifications. Veuillez vérifier ma réponse pour ma suggestion.
7ochem
2

Malheureusement, la réponse acceptée, bien qu'elle soit à l'origine destinée à atteindre l'objectif souhaité, ne fonctionne que pour exclure les fichiers et répertoires placés à la racine, car si nous voulons exclure un fichier placé dans un sous-répertoire (par exemple dev/tools/grunt/configs/themes.js, si nous ajoutons un nouveau thème et souhaitez utiliser les tâches Magento Grunt), en le plaçant dans la configuration "magento-deploy-ignore", il bloque le déploiement de tous les répertoires parents (c'est-à-dire, dev et tous ses sous-répertoires).

Cela se produit car la méthode qui traite le "magento-deploy-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) utilise strpospour faire correspondre le chemin de destination à la liste des exclus, donc chaque chemin parent retournera toujours vrai.

Gennaro Vietri
la source
Je sais, j'ai pu le voir dans mes tests, mais puisque nous utilisons un workflow de construction différent, cela fonctionne bien pour nous atm. Pourriez-vous trouver une meilleure option?
fmrng
Nous avons commencé à vérifier les fichiers pendant la phase de construction de notre pipeline, puis nous avons cessé d'utiliser toutes les tâches Grunt intégrées, donc ce n'est pas un problème pour atm.
Gennaro Vietri
Soit dit en passant, nous avons commencé à évaluer fork magento-composer-installer pour améliorer le comportement "magento-deploy-ignore", si le problème devait réapparaître, nous pourrions suivre ce chemin
Gennaro Vietri
0

Utilisation de correctifs

Ce que j'utilise, c'est créer et appliquer des correctifs. Lorsque nous devons changer dev/tools/grunt/configs/themes.js, index.phpou .htaccessappliquer les modifications à une copie temporaire du fichier et en créer un patch (créez d'abord un build/répertoire):

$ cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp
  # Now Make changes in .tmp file
$ diff -u3 dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp | sed 's/\.tmp//' > build/themes.patch
$ mv dev/tools/grunt/configs/themes.js.tmp dev/tools/grunt/configs/themes.js

Ensuite, nous pouvons appliquer ce correctif automatiquement lors de l'exécution composer installou updateen ajoutant des commandes te à la scriptssection de votre composer.jsonfichier:

{
    "scripts": {
        "post-install-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js",
        "post-update-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js"
    }
}

(Vous pouvez également placer la patch ...commande ci-dessus dans un script bash, disons build/themes_patch.shet appeler ce script depuis Composer pour qu'il soit réutilisable ou exécutable manuellement)

Mettez à niveau en toute sécurité! :RÉ

Cette solution est mise à niveau en toute sécurité! Vous ne modifiez pas directement les fichiers principaux sans respecter le fichier d'origine. Vous appliquez un correctif au fichier Magento2 d'origine. Lorsque ce fichier change parce que vous effectuez une mise à niveau, le correctif échoue et vous savez que vous devez examiner de plus près les nouvelles modifications et créer un nouveau correctif.

7ochem
la source