Processo di distribuzione di Magento 2

8

Attualmente ci impegniamo composer.locknel repository e quindi eseguiamo composer install --no-devsul server di produzione. Non penso che questo sia il modo migliore per farlo perché il compositore impiega alcuni minuti per generare tutti i file ed è rischioso.

Mi chiedo se è meglio impegnare nel repository tutti i file necessari per l'esecuzione in modalità di produzione.

In che modo gli altri gestiscono il processo di distribuzione con magento 2?

magento2 composer deployment

— Claudiu Creanga
fonte

Perché è rischioso? Deve essere eseguito una sola volta per installazione / configurazione e, una volta scaricato un pacchetto, il compositore viene memorizzato nella cache.

— user3668514

forse mi manca qualcosa ma se non si dispone della cartella del fornitore nel repository come si installerebbero nuovi moduli senza essere eseguiti composer installin produzione? letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

— Claudiu Creanga

Il punto è correre composer install. Hai esaminato un hook git per automatizzare il processo?

— user3668514

@ user3668514 cosa succede se, quando si esegue l'installazione del compositore in produzione, alcuni pacchetti remoti sono inattivi, come è successo con npm?

— Claudiu Creanga,

quanto spesso succede? Magento2 ora viene fornito con un .gitignore che ignora esplicitamente / fornitore tra gli altri. Poiché questo è il nuovo "modo Magento", lo sto seguendo per garantire che altri sviluppatori possano lavorare al progetto senza problemi

— user3668514

5

Concorda al 100% con claudiu-creanga di non impegnare il venditore e di evitare di eseguire l'installazione del compositore in produzione.

Il modo in cui abbiamo gestito questo è di avere una cartella live e una cartella candidata al rilascio. È nella cartella candidato alla pubblicazione che eseguiamo i comandi git pull e l'installazione del compositore --no-dev. Il nostro processo può essere riassunto in questo modo:

Nella cartella candidato alla versione:
- Controlla eventuali cambiamenti imprevisti
- Aggiorna repository
- Installazione del compositore
Sincronizza i file nella cartella del sito live
Nella cartella del sito live:
- Distribuire file statici
- Abilita modalità di manutenzione
- Abilita i moduli
- Esegui script di installazione
- Compila DI
- Cancella cache
- Disabilita la modalità di manutenzione
- Autorizzazioni di aggiornamento

Ho scritto un articolo sul blog più lungo che fornisce i comandi e il ragionamento reali dietro questo: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

AGGIORNAMENTO: Ora copiamo il database live in un database di gestione temporanea e lo utilizziamo per eseguire script di installazione, distribuire file statici e compilare DI tutti offline. Questo può quindi essere distribuito per vivere compresi i file pub / static e var. Rimuoviamo ancora brevemente il sito se vengono eseguiti gli script di installazione, ma altrimenti il sito viene lasciato su. Maggiori dettagli su https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/

AGGIORNAMENTO: ho cambiato idea sull'impegnare la cartella del fornitore - impegnando la cartella si ottiene la possibilità di tenere traccia della cronologia di come questi file cambiano, vedere se si è accidentalmente cambiato qualcosa e, soprattutto, si evita di eseguire Composer al momento dell'implementazione. Quest'ultimo è di vitale importanza ora che ci affidiamo a fornitori esterni di repository. Cosa succede se uno di questi non è disponibile? Improvvisamente non è possibile distribuire. Gli svantaggi sono un archivio più grande, il rischio di commettere hack core e la scossa di sviluppatori come me :)

— Robert Egginton
fonte

Abbiamo anche iniziato a eseguire il commit dell'app / etc / config.php. Questo è di default ignorato da .gitignore di Magento 2, ma commettendo questa abilitazione e disabilitazione viene fatto durante lo sviluppo e tale decisione viene quindi impegnata e può essere propagata e testata tramite CI.

— Robert Egginton,

Trasformi seriamente il tuo sito web offline? Questa non è un'opzione per noi. La nostra azienda sta effettivamente facendo soldi

— TheBlackBenzKid

Al momento sì, mettiamo brevemente i siti offline poiché non siamo sicuri al 100% che gli utenti non vedrebbero un sito parzialmente operativo. Con la nostra maggiore esperienza di M1, sappiamo con un certo grado di certezza quali modifiche possono essere applicate senza smontare il sito. Non ancora con M2.

— Robert Egginton,

Up-votato. Tuttavia, come @TheBlackBenzKid, mi piacerebbe vedere qualcosa che non mette offline il tuo sito Web, soprattutto perché la compilazione DI richiede un po 'di tempo. Penso che comprendere ciò che effettivamente fa la compilazione DI sia la chiave - sarebbe bello se quel passo potesse essere fatto nella cartella candidato alla release. Qualche progresso nel frattempo da quando hai pubblicato questo @Robert?

— Erfan,

1

Interessante modifica @RobertEgginton - Attualmente sto esplorando questo e ho seguito i tuoi post e discussioni. Condivido le riserve sull'uso del compositore al momento della distribuzione e sulla potenziale indisponibilità dei repository di terze parti, anche se presumo che ciò sia meno preoccupante per i repository packagist. Commettere ./vendor sembra anche meno che ideale ma almeno ti dà una versione completa che può essere distribuita indipendentemente dai repository di terze parti. Hai provato l'estensione Capistrano Magento2? Questo utilizza l'installazione del compositore, ma mi piace il flusso di lavoro del cappuccio github.com/davidalger/capistrano-magento2

— BlueC

3

Finora abbiamo anche impegnato la cartella del fornitore, che ovviamente aggiunge molti file al tuo repository. (Assicurati di rimuovere tutte le cartelle .git nei file del compositore del fornitore, altrimenti il contenuto delle cartelle non verrà eseguito, ad esempio firegento). Ma il collegamento simbolico alla cartella del fornitore non funziona, inoltre la modifica del percorso nel file vendor_path.php non funziona e non abbiamo ancora avuto il tempo di cercare una soluzione migliore.

Non abbiamo un server di compilazione e non eseguiamo compositore sul server, eseguiamo e testiamo tutti gli aggiornamenti localmente e li eseguiamo. Questo a sua volta attiva il nostro script di distribuzione.

Il nostro script di distribuzione sostituisce il file env.php, fa alcune cose personalizzate e quindi si innesca setup:upgradee setup:static-content:deployprima di cambiare il collegamento live nella nuova cartella.

L'unica cartella che link simbolico è pub / media.

— tecjam
fonte

Grazie per l'input. oltre a cambiare env.php quali sono le altre modifiche che vorresti apportare?

— Claudiu Creanga,

Tutto dipende dal tuo server e dalla configurazione del progetto, immagino. Per i rami dev & staging, eliminiamo anche .htaccess e copiamo i nostri file .htaccess & htpassword nella directory, assicurandoci che bin / magento sia eseguibile come precauzione prima di eseguire i comandi cli su di esso, che ci assicuriamo corriamo come proprietario del file magento (l'utente della distribuzione è root) e colleghiamo la cartella media alla cartella pub. Ovviamente potresti aggiungere qualsiasi altra cosa che preferisci fare durante la distribuzione piuttosto che in precedenza.

— tecjam,

Il commit di file in / fornitore è generalmente sconsigliato in quanto vanifica l'obiettivo di un componente manager. Vedi la documentazione del compositore.

— user3668514

Questo è chiaro. Allora come gestisci la tua distribuzione?

— Tecjam,

1

Attento @ user3668514 - Penso che intendi l'installazione del compositore. È facile eseguire inavvertitamente l'aggiornamento e modificare effettivamente i componenti anziché installarli.

— Robert Egginton,

2

Alla fine abbiamo optato per un servizio come deploybot( http://deploybot.com/ ). Puoi usarecapistrano che è gratuito. Deploybot crea un contenitore docker mentre l'installazione del compositore è in esecuzione e, se il comando ha esito positivo, distribuisce il codice, altrimenti non distribuirà nulla, quindi l'ambiente di produzione sarà sicuro.

Considero questo l'approccio migliore perché:

1) avere la cartella del fornitore nel tuo repository git non è raccomandato dai compositori per buoni motivi:

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Maggiori informazioni: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) Correre composer install in productionsenza reti di sicurezza è rischioso , i pacchetti potrebbero essere inattivi (vedi npm), potresti incorrere in problemi di memoria o qualunque errore si possa verificare mentre il compositore genera file e dovrai affrontare un ambiente di produzione rotto.

— Claudiu Creanga
fonte

1

Sto anche esaminando questo, l'approccio che ho adottato finora è:

Avvio automatico del server:

Imposta il progetto con composer --create-project ... --no-devin asrc cartella (anche se vedo ancora molti dev cruft passare)
App di installazione, compilazione di file statici, aggiornamento db ecc.
Imposta tutte le autorizzazioni corrette

Il che mi darà uno stock, eseguendo il negozio dalla mia directory src (ma il mio webroot non punta lì)

Quindi il mio processo di distribuzione:

Crea una nuova cartella di rilascio
rsincronizza i file src nella mia versione (esclusa la cruft)
distribuire e decomprimere le mie personalizzazioni sopra (una manciata di file di temi e moduli)
installare eventuali moduli magento di terze parti tramite magento connect
punta i miei host webroot alla mia nuova versione (con un link simbolico)
ricaricare con grazia il mio server web

Questo mi permette di mantenere il codice core di Magento separato dal mio, usare il compositore per tenerlo aggiornato .. e non ho bisogno di spedire 39.102 !!! file con ogni distribuzione, oppure eseguire i comandi del compositore al momento della distribuzione.

... Mi piacerebbe conoscere altri approcci o le migliori pratiche su questo, e mi piace anche sapere quali file sono effettivamente richiesti per la produzione e quali sono dev .. in modo da poter mantenere pulito il mio webroot.

Una volta finito, avrò un playbook sensibile e alcuni comandi Fabric per orchestrare la configurazione e la distribuzione, che sono felice di condividere.

spero che aiuti

— farridav
fonte

Mi piacerebbe vedere i libri di testo e gli script.

— JM Becker,