Qual è la struttura preferita di un progetto Magento 2 sotto VCS?

15

Quando avvio un nuovo progetto M2, la prima cosa che vorrei fare è installare il core tramite compositore:

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

Ora posso scrivere i miei moduli personalizzati e i miei temi in app/code. Vorrei quindi aggiungere la mia composer.*e l'intera app/codecartella al mio VCS. Finora tutto bene.

Supponiamo che ora voglia usare alcuni strumenti di costruzione per il mio progetto, diciamo Grunt o Gulp.

Se commetto il mio Gruntfile.js, questo verrà sovrascritto dal magento/magento2-basepacchetto quando corro composer installdopo aver clonato il repository.
Se commetto il mio gulpfile.js, non posso davvero definire le mie dipendenze in a package.json, perché sarebbe anche sovrascritto da magento/magento2-base.
Se decido di utilizzare il programma di installazione di Grento di Magento e voglio personalizzarlo modificando i file in /dev/tools/grunt(ad es. themes.js), Non posso perché le mie modifiche verrebbero sovrascritte magento/magento2-base.

La mia comprensione è che non puoi davvero fare molto nella radice del tuo documento. Esistono ovviamente molte soluzioni a questo problema:

Potrei eseguire git checkout -subito dopo l'installazione per ripristinare i miei file
Potrei archiviare i miei file di build in una cartella dedicata, /buildad esempio
Potrei usare uno strumento di costruzione diverso, come Phing, Ant o Rake (i miei sviluppatori frontend non sarebbero così felici)
Potrei sostituire magento/magento2-basecon un pacchetto personalizzato che ha una mappatura personalizzata per i file core (non proprio ottimale ma ehi, è un'opzione)

Personalmente non mi piacciono tutte queste opzioni, quindi vorrei sapere se esiste un modo preferito o migliore per ottenere ciò che sto cercando di fare.

qualcuno sta avendo lo stesso problema? come l'hai risolto? Come strutturi il tuo progetto in VCS?

AGGIORNARE

Un punto in più legato alla configurazione del progetto. Nei miei esperimenti ho notato che il programma di installazione del compositore Magento ha un flag per l'override dei file:

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

È considerato internamente come un valore booleano se non sbaglio, quindi ho cercato di impostarlo falseper saltare l'override. Quando eseguo la composer installmia installazione non riesce a causa dei file già presenti. Fondamentalmente, se non lascio che Magento sovrascriva i miei file, non posso installarlo.

Qual è lo scopo di questa bandiera allora? Supponiamo solo di eseguire un controllo per me? Non ha molto senso per me essere sincero, ma forse qualcuno può fare luce sull'argomento.

— fmrng
fonte

Sono curioso di vedere cosa pubblicano gli altri come risposta. Idealmente, penso che vorremmo tenere Magento Core fuori dal nostro repository principale e limitarlo al solo modello che creiamo e ai plug-in personalizzati che aggiungiamo o che aggiustiamo. Quindi al momento della compilazione, facciamo riferimento al core + repository del nostro progetto e costruiamo un artefatto dell'applicazione dai repository. Questo è il metodo che ho usato di recente per M1 e mi chiedo se la raccomandazione ufficiale di Magento sia quella di fare qualcosa di simile con M2 ora che Composer è pienamente supportato.

— Bryan 'BJ' Hoffpauir Jr.

Nelle versioni più recenti M2, il Gruntfile.js, gulpfile.jse package.jsonproblema è risolto. Il problema risolto in questa domanda è ancora applicabile alle versioni più recenti di Magento 2 quando è necessario modificarle o themes.js, ad esempio. index.php.htaccess

— 7

4

A breve termine, stiamo cercando di separare i file che necessitano di personalizzazione. Ad esempio, se le persone devono modificare index.php, capire come separare il file standard fornito da Magento dalla necessità di personalizzazioni locali. Una volta raggiunto, è possibile avere "un vero .gitignore per tutti i progetti utilizzabili". Cioè, è facile affidare l'intera directory del progetto a Git con .gitignore di tutto ciò che "installazione del compositore" prenderà per te (e tutto ciò che "aggiornamento del compositore" sostituirà durante l'installazione di una patch o di un aggiornamento).

A più lungo termine, l'obiettivo è abbreviare il più possibile .gitignore. Ad esempio, spingi di più nei moduli nella directory "vendor".

Poi

Per tutto ciò che non desideri condividere tra i progetti, lascialo sotto app / codice e impegnato nel repository principale del progetto.
Tutto ciò che è stato sviluppato localmente si desidera condividere più facilmente tra i progetti, inserire un repository GIT separato e installarlo tramite il compositore in modo che finisca sotto "fornitore". (Potrebbe essere un repository del compositore locale o semplicemente installarlo direttamente da GIT.)

In questo modo puoi ancora eseguire il commit dell'intero albero del progetto dall'alto verso il basso, catturando i file composer.json e composer.lock (il commit di solo app / codice non lo fa). .Gitignore esclude la directory "vendor" e altri file non desiderati.

Questo ti dà il meglio dei due mondi menzionati nell'altra discussione. L'attuale dolore è la lunghezza e la complessità del file .gitignore e l'installazione della patch attualmente cancella alcune personalizzazioni locali (ad esempio in index.php). Soluzione a breve termine: rimuovi index.php da .gitignore e quando installi una patch controlla per vedere quali cambiamenti hai perso (git diff) e riapplicali manualmente.

— Alan Kent
fonte

OK, quindi cambierai alcune cose lì nel prossimo futuro, bello! Mi chiedo se questa "magento-force": "override"bandiera possa essere utile in qualche modo. Al momento non sta esattamente facendo ciò che mi aspetterei. Nel caso in cui tu abbia modificato / esteso il tuo index.phpo qualsiasi altro file "core", potresti semplicemente dire a Magento di non sovrascrivere le tue modifiche. Ha senso?

— fmrng,

3

Esiste una soluzione semplice per il tuo override Problema: non cambiare i file principali;) Magento si basa sull'estensione del codice e non sulla sua modifica.

La prima cosa è che non dovresti mettere l'intera cartella app / codice in un repository vcs. Ogni componente Magento (modulo, tema, ecc ...) dovrebbe essere un repository stesso.

Se vuoi cambiare / estendere il frontend, dovresti creare un nuovo tema e considerare questo tema come il tuo progetto grugnito, non l'intera istanza di Magento2.

Per installare il tuo tema nel tuo Progetto, puoi facilmente inserirlo tramite il compositore direttamente dal tuo repository vcs

— David Verholen
fonte

Bene, la app/codecartella è appositamente lì per personalizzare Magento. La mia comprensione dell'attuale M2 è che app/codesostituisce ciò che app/code/localera in M1 e i moduli della comunità possono essere installati tramite il compositore sotto vendor. Abbiamo alcuni progetti con un GRANDE numero di moduli e anche diversi temi. Quello che stai suggerendo sarebbe impossibile da gestire.

— fmrng,

Ehi, gestiamo progetti con> 100 componenti in questo modo. La chiave è mantenere piccoli moduli e gestire le dipendenze del tuo compositore tra i moduli. Puoi clonare il repository di progetti magento per le tue esigenze e aggiungere tutti i componenti al tuo progetto

— David Verholen,

Se sei soddisfatto della tua configurazione attuale, va bene. Onestamente, lo trovo piuttosto ingombrante. Significa che hai oltre 100 repository git e ogni volta che cambi qualcosa devi aprire un progetto specifico, eseguire il commit delle modifiche ed eseguire composer update. Dove commetti il tuo composer.lockallora? Se hai più di 10 sviluppatori che lavorano allo stesso progetto, potrebbe risultare davvero disordinato. Ovviamente abbiamo un sacco di moduli generali (e persino temi) che installiamo tramite il compositore, ma per motivi di chiarezza il codice specifico del progetto dovrebbe essere aggiornato sotto lo stesso repository.

— fmrng,

Non sto dicendo che stai sbagliando, penso che sia un po 'troppo complicato per i miei gusti. Per interesse, come controlli la cronologia dei repository con una configurazione del genere? Come è possibile utilizzare funzionalità come git blameo git logquando il codice è sparso in più componenti? Esegui test di integrazione per verificare che tutto funzioni correttamente?

— fmrng,

abbiamo discusso internamente lo scorso anno e le implementazioni sono diventate piuttosto semplici da quando abbiamo deciso di renderlo 1repo = 1module. Il punto è che non faresti un aggiornamento del compositore per una piccola modifica. Gli sviluppatori lavorano in ambienti di sviluppo e cambiano i file direttamente lì. Quando hanno finito, possono etichettarlo come alpha, beta o release candidate. In questo modo, diversi sviluppatori possono lavorare su più progetti contemporaneamente e la volta successiva, esegui un aggiornamento del compositore e attiri tutte le modifiche. Ci sono ottimi strumenti per organizzare i tuoi pacchetti vcs e compositori.

— Centinaia

2

Ok, sembra che ho trovato una soluzione migliore per quello che stavo cercando di ottenere. In composer.json, è possibile specificare quali file devono essere ignorati dal programma di installazione di Magento Composer. Se non voglio Gruntfile.jsche venga sovrascritto, posso semplicemente specificarlo con la seguente configurazione:

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

Ora sono in grado di estendere l'installazione standard per soddisfare le mie esigenze.

— fmrng
fonte

Questa soluzione non sembra "upgrade sicuro". Se Magento apporterà modifiche a questi file che ignori, non lo saprai o ti dimenticherai di questi file. Stai utilizzando la tua versione che non includerà mai queste nuove modifiche. Controlla la mia risposta per il mio suggerimento.

— 7

2

Sfortunatamente la risposta accettata, pur essendo il modo in cui originariamente intendeva raggiungere l'obiettivo desiderato, funziona solo per escludere file e directory inseriti nella radice, perché se vogliamo escludere un file inserito in una sottodirectory (ad es. dev/tools/grunt/configs/themes.js, Necessario se aggiungiamo un nuovo tema e desidera utilizzare le attività di Magento Grunt), inserendolo nella configurazione "magento-deploy-ignore", blocca la distribuzione di tutte le directory principali (vale a dire dev e tutte le sue sottodirectory).

Ciò accade perché il metodo che elabora "magento-deploy-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) utilizza strposper far corrispondere il percorso di destinazione all'elenco di esclusi, quindi ogni percorso principale restituirà sempre true.

— Gennaro Vietri
fonte

Lo so, ho potuto vederlo nei miei test, ma dato che stiamo usando un flusso di lavoro di build diverso, funziona bene per noi atm. Potresti trovare un'opzione migliore?

— fmrng,

Abbiamo iniziato a fare il checkout dei file durante la fase di compilazione della nostra pipeline, quindi abbiamo smesso di utilizzare tutte le attività Grunt integrate, quindi non è un problema.

— Gennaro Vietri,

A proposito, abbiamo iniziato a valutare fork-magento-compositore-installatore per migliorare il comportamento "magento-deploy-ignore", se il problema dovesse ripresentarsi potremmo seguire questo percorso

— Gennaro Vietri,

0

Usando le patch

Quello che uso è la creazione e l'applicazione di patch. Quando abbiamo bisogno di cambiare dev/tools/grunt/configs/themes.js, index.phpo .htaccessapplichiamo le modifiche a una copia temporanea del file e ne creiamo una patch (crea build/prima una directory ):

$ 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

Quindi possiamo fare in modo che questa patch si applichi automaticamente durante l'esecuzione composer installo updateaggiungendo i comandi te alla scriptssezione del tuo composer.jsonfile:

{
    "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"
    }
}

(Inoltre potresti inserire il patch ...comando sopra in uno script bash, diciamo build/themes_patch.she chiamiamo quello script da Composer in modo che sia riutilizzabile o eseguibile manualmente)

Aggiornamento sicuro! : D

Questa soluzione è sicura per l'aggiornamento! Non si modificano direttamente i file core senza rispettare il file originale. Stai applicando una patch al file Magento2 originale. Quando quel file cambia a causa dell'aggiornamento, la patch fallirà e sai che devi dare un'occhiata più da vicino alle nuove modifiche e creare una nuova patch.

— 7ochem
fonte