GIT e strategia di implementazione progetti Magento2

92

Con Magento 1 ho usato uno strumento di distribuzione che ha inserito il repository GIT, eseguito comandi simili modman deploy-alle verificato che la vardirectory fosse scrivibile. Per questo .gitignoreho usato questo che ha funzionato abbastanza bene.

Ma che dire di Magento 2 ?

Quale gitignore funziona meglio, come si distribuisce il progetto e quale comando si dovrebbe eseguire prima e dopo la distribuzione. Non vedo l'ora di ascoltare alcuni approfondimenti della community.

La domanda rimarrà aperta per un bel po 'di tempo

magento2

— Levigatrice
fonte

Bella domanda @sander Mangel

— Amit Bera

1

Per definizione non ci può essere una risposta canonica a questo, quindi è probabilmente troppo ampia e anche inadeguata per la natura di domande e risposte del sito. Probabilmente dovrebbe essere meta. Ma lo sai già. Detto questo, lo permetterò fino alla scadenza della taglia.

— Philwinkle,

@philwinkle potrebbe essere ampio ma apparentemente non troppo ampio dato che già sono state fornite 3 risposte. Come discusso qui: meta.magento.stackexchange.com/questions/745/… Meta deve essere usato per domande su MageSE, non per messaggi / domande casuali Se vuoi cancellarlo non posso fermarti ma sembra molto le persone sono interessate alla domanda e secondo me è valida, anche se non è troppo specifica.

— Sander Mangel

Due cose: in primo luogo, Sander ha ragione su Meta: dovrebbe essere usato solo per domande sulla piattaforma SE in relazione a Magento SE (NB: forse non abbiamo controllato Meta abbastanza bene per rafforzare questa regola). In secondo luogo, "molte persone [interessate] a una domanda non hanno nulla a che fare con la possibilità di rispondere in modo canonico a una domanda (e quindi con l'idoneità di una domanda al formato StackExchange). È frustrante di sicuro (mi sono scontrato con me stesso). Sono propenso a vedere dove va questo thread Q / A. Forse una A può essere dichiarata abbastanza bene da essere esclusivamente "giusta" ...

— benmarks

@benmarks in quel caso ho scelto il motivo o l'oggetto sbagliato per la generosità, la mia motivazione alla base era quella di premiare chi si è preso il tempo di scrivere una risposta completa per questo. Se questo thread non appartiene a questo, lo copierò e lo pubblicherò da qualche parte online accreditando gli autori poiché ritengo che abbia ancora valore. Per favore avvisami se prima di cancellare

— Sander Mangel

56

I passaggi seguenti descrivono come impostare l'ambiente per lo sviluppo di moduli personalizzati, non per la produzione.

Inizializzazione del progetto

Aggiungi le credenziali repo.magento.com e il token di accesso github a auth.json nella home directory del compositore
Crea progetto usando il seguente comando:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
Prendi questo .gitignore e inseriscilo nella radice del tuo progetto. Quasi tutti i file / directory principali sono già stati aggiunti alla radice .gitignore, ma è meglio aggiungere anche i seguenti 2 /updatee /phpserver(basta aggiungere queste 2 righe a .gitignore)
Inizializza il nuovo repository git nella radice del progetto
Aggiungi tutti i file non tracciati a git e esegui il commit
Inizia lo sviluppo dei tuoi moduli come al solito (mettili sotto app/code/VendorName/ModuleName), ora avrai solo il tuo codice personalizzato nel tuo repository git

Installazione di Magento

Assicurati che tutte le autorizzazioni del filesystem siano impostate come indicato nella guida ufficiale
Installa Magento utilizzando la riga di comando, ad esempio:

${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ --admin-email=admin@example.com \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1
Abilita cronizzatore indicizzatori, ad es. Su Ubuntu:

echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -
Magento verrà eseguito in defaultmodalità e tutto il contenuto mancante verrà generato automaticamente alla prima richiesta. Quindi non è necessario eseguire compilatore o distribuire contenuto statico
[opzionale] Se si utilizza PHP Storm, eseguire il comando seguente per abilitare il supporto XSD:

bin/magento dev:urn-catalog:generate .idea/misc.xml

— Alex Paliarush
fonte

Ciao Alex. Inizializzazione del progetto passaggio 3: potresti espanderlo un po '? Hai trovato che dovevi copiare manualmente quella sottodirectory nella radice? (Mi chiedo se c'è qualcosa che non funziona correttamente - non mi aspettavo quel passaggio.)

— Alan Kent il

@AlanKent attualmente puoi scaricare tutti i file relativi a Magento vendor, incluso magento2-base, che è solo uno scheletro per un nuovo progetto. Non so perché questo passaggio non sia configurato per essere eseguito automaticamente dal compositore, proverà a scoprirlo. Per quanto riguarda la .gitignorecopia da un altro repository, è già in discussione come eliminare / semplificare questo passaggio.

— Alex Paliarush,

Il passaggio 3 non è richiesto. Il marshalling dei file / cartelle viene eseguito durante il passaggio 2.

— Maddy,

Grazie @Maddy. @AlanKent, la copia magento2-basenella radice non è più necessaria (appena verificata), sembra essere stata corretta di recente. Rimosso questo passaggio dalla risposta.

— Alex Paliarush,

1) Ho messo tutto il mio codice sul repository, già non installato e tutto, quando estraggo da quel repository e modifico semplicemente le impostazioni di admin pangel e le credenziali db, tutto funzionerà correttamente? 2) poiché ho dimenticato di escludere var / e pub / folder durante il push, posso eliminarli completamente, in modo che possano eliminare sul repository remoto, si rigenereranno? Grazie.

— Lachezar Raychev,

25

Per l'inizializzazione e l'installazione segui i passaggi di Alex la sua risposta per la maggior parte dei passaggi, solo le differenze che consiglierei:

Configurazione Git

Memorizza solo i seguenti file nel tuo repository Git:

composer.json
composer.lock
app / etc / config.php

Per il codice personalizzato del tuo progetto, usa anche moduli separati che includi attraverso il compositore. La gestione di questo compositore è più semplice in quanto è possibile bloccare una versione / versione specifica che si desidera distribuire. Questo ti costringe anche a utilizzare lo stesso approccio per i moduli interni ed esterni.

Distribuzione

Durante lo sviluppo aggiorni i moduli sul tuo ambiente (dev / test) con il comando:

composer update

Ciò aggiornerà il file composer.lock con le versioni installate su tale installazione.

In fase di messa in scena / pre-produzione / produzione è possibile creare / installare la stessa configurazione con il comando:

git pull
composer install

Ciò installerà tutti gli stessi moduli utilizzati in dev / test per garantire che i test prima della pubblicazione in produzione vengano eseguiti con le stesse versioni dei moduli con cui è stato sviluppato.

Dopo l'installazione per eseguire i seguenti comandi:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

Ciò aggiornerà il database (aggiornamento dello schema e dei dati), genererà la configurazione DI e distribuirà tutti i file di visualizzazione statici.

— Vladimir Kerkhoff
fonte

Forse ha senso usare dati campione invece di generare dispositivi? I dispositivi popolano solo i moduli più critici e sembrano essere utili solo per i test delle prestazioni.

— Alex Paliarush,

Grazie, rimosso quella parte in quanto non è necessaria quando si utilizza un sito in produzione.

— Vladimir Kerkhoff,

Questo segue molto da vicino anche l'approccio che sto usando. Funziona bene anche con Magento 1 (con un processo di compilazione meno complesso). Lascia che compositore faccia il suo lavoro, funzioni per le implementazioni davvero bene nella mia esperienza e non abbiamo visto molti aspetti negativi oltre alle complessità con la strategia .gitignore quando non seguire il footprint più piccolo in git.

— Aepod,

Questa installazione sembra il modo 'integratore'. Aggiunge i repository in vendor / magento / *. Nessun codice sarà in app / code / .. e altre directory. Come avrei le directory principali di Magento 2 come nell'archivio .zip. È possibile aggiungere tramite compositore un modulo (altro git repo) e poi finire automaticamente in app / codice / ...?

— oscuro

4

rischioso, il compositore non è uno strumento di distribuzione. se qualcosa non riesce durante l'installazione del compositore durante l'esecuzione in produzione ...

— Claudiu Creanga,

3

Re .gitignore, 2.2 in poi la risposta ufficiale di Magento sarà "config.php va in git, env.php no".

Stiamo esaminando plugin per compositori come Mediawiki per avvicinare gli sviluppatori interni allo sviluppo delle estensioni e ai siti dei clienti. Ancora in esplorazione, non ancora definitivo.

Mi è abbastanza piaciuto usare il tipo di repository "Path" del Compositore con un percorso ../othergitrepo/app/code/*/*per raccogliere i moduli, ma usa collegamenti simbolici che non funzionano così bene con gli ambienti di sviluppo che usano Unison o simili.

— Alan Kent
fonte

3

adottiamo un approccio diverso che non prevede un build-server / processo separato , che sviluppiamo localmente come nella produzione

quindi eseguiamo il commit di tutti i file necessari per la produzione . quindi semplicemente implementiamo i changeset sul server ed eseguiamo il comando upgrade.

arrivare a una versione adatta allo sviluppo ma anche in modalità di produzione è stata la parte difficile e non è ancora perfetta, ma ora abbiamo una ricetta che funziona.

il motivo è che vogliamo avere il controllo al 100% su quale codice va in produzione. poiché magento2 genera una tonnellata di codice, dobbiamo eseguirlo localmente per essere in grado di comprendere tutti gli effetti e poter eseguire il debug come se fosse in produzione.

Sono consapevole che questo non è ciò che molte persone consigliano di fare, ma per noi funziona meglio.

passaggi di installazione del frontend

Affinché questi script funzionino, imposta il tuo negozio in modalità di produzione nel tuo env.php e imposta il tuo tema dev/tools/grunt/configs/themes.js. (i seguenti passaggi sono stati inseriti in un playbook sensibile)

Elimina var/cache
Elimina var/view_preprocessed
elimina pub/static/*(non eliminare .htaccess)
Elimina var/composer_home
correre php bin/magento cache:flush
correre php bin/magento setup:static-content:deploy %your_languages%
elimina tutti i temi / lingue che non usi effettivamente da pub / static / frontend
rimuovere le copie cartacee di meno file da pub/static/frontend
correre php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
facoltativo: usiamo uno script bash per cambiare i collegamenti simbolici assoluti, creati nel passaggio 9, in quelli relativi, rendendo possibile eseguire grunt dall'esterno della VM
correre grunt less:your_theme

passaggi back-end / di-setup

Elimina var/cache
Elimina var/generation
Elimina var/composer_home
Elimina var/di
correre php bin/magento cache:flush
correre php bin/magento setup:di:compile

— greenone83
fonte

Grazie per questo @ greenone83, questo è l'approccio che ho sostanzialmente adottato, anche se ho generato il mio backend come parte del front-end. Non uso MAI setup: di: compile perché trovo che rovini tutto! Una cosa che non capisco è perché setup: static-content: deploy crea file in generato / codice (la posizione è cambiata dal tuo post)? Ho scoperto che se elimino tutto il codice / generato, con il mio sito in modalità di produzione questi file vengono creati automaticamente quando sfoglio il sito.

— PedroKTFC,

2

Dovresti ignorare anche questi file
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

— mrtuvn
fonte

2

Se ignori config.php dovrai abilitare di nuovo la nuova estensione dopo averlo spinto in un altro ambiente, quindi è meglio includerlo nel tuo repository.

— Vladimir Kerkhoff,