Gestire Magento / Composer / Deployment


18

Quindi, mi diverto ad usare il programma di installazione Magathon Composer di hackathon, ma faccio fatica a capire come gli altri lo usano in relazione a un servizio di distribuzione. Attualmente sto usando DeployHQ, e sì, posso impostarlo per distribuire ed eseguire il compositore quando c'è un aggiornamento al repository, ma questo non ha senso per me ora.

Il mio repository principale del compositore, contenente solo il file json di tutti i pacchetti che voglio includere nella mia build, viene aggiornato solo quando aggiungo un nuovo pacchetto all'elenco.

Quando aggiorno il mio tema o estensione personalizzata (a cui si fa riferimento nel file json), non esiste un "hook" per aggiornare il mio servizio di distribuzione. Quindi devo accedere al mio server ed eseguire manualmente compositore (che rimuove il sito fino al termine).

Quindi come fanno gli altri a gestirlo? Devo eseguire il compositore solo localmente e includere la cartella del fornitore nel mio repository?

Qualsiasi risposta sarebbe molto apprezzata.


4
Sto votando per chiudere questa domanda come fuori tema perché riguarda Composer.
mbalparda,

1
Ciao, in particolare, è legato all'uso di Magento con il compositore e più specificamente alla funzionalità hackathon di Magento. Quindi penso che tu sia stato un po 'prematuro in quella scusa!
James Allwood,

È davvero complesso da spiegare, ma ci proverò: poiché penso che questa domanda non sia correlata a Magento e tu pensi che lo sia, l'ho contrassegnato come Off topic. Se un moderatore o altri 4 membri decidono che deve essere chiuso lo farà. In caso contrario, rimarrà aperto. Il messaggio è automatico quando si contrassegna la domanda come fuori tema. Ed è certamente fuori tema perché l'argomento principale è il compositore, legato a Magento ma può essere applicato a qualsiasi altra installazione di software e potrebbe appartenere a un sito su server / distribuzioni e non in Magento SE secondo me.
mbalparda,

1
Ragazzi, questa domanda ha ricevuto 2 voti positivi e un preferito. Sicuramente consentire a qualcuno di rispondere a questa domanda non può nuocere? Aiuterà gli altri nella comunità di
MAGENTO

@JamesAllwood come sei andato con questo?
jharrison.au,

Risposte:


13

Ho creato una struttura presso la nostra agenzia che ci consente di utilizzare Composer per distribuire tutti i nostri siti Magento. Questo potrebbe essere un po 'eccessivo per la domanda che hai posto, ma ecco comunque una panoramica di base della struttura:

Struttura del deposito

Di seguito è riportata la struttura delle cartelle del repository 'parent'. Contiene il compositore JSON, i file di blocco e altre configurazioni necessarie per la distribuzione.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock
  • Tutte le personalizzazioni specifiche del client vengono archiviate in un modulo "personalizzazioni" separato che viene installato utilizzando Composer
  • Il core di Magento è incluso come sottomodulo Git ( code/magento)
  • Una index.phpcartella personalizzata e altre come media ed errori si trovano all'interno di una cartella pubblica al di fuori della radice di Magento
  • I file specifici dell'ambiente (local.xml, robots.txt, ecc.) Vengono collegati simbolicamente alla radice Magento durante il processo di distribuzione
  • La cartella del fornitore è esclusa da Git, ma è incluso il file composer.lock.

Distribuzione

  • Distribuiamo utilizzando Capsitrano che consente più server e ambienti di app (gestione temporanea / produzione)
  • Capistrano crea l'intera base di codice sul server in una nuova cartella, quindi scambia il link simbolico webroot alla fine, il che significa che non ci sono tempi di inattività per il tuo sito web.
  • Capistrano viene eseguito composer installdurante la compilazione e distribuisce tutti i moduli nel sottomodulo Magento.

Questa non è ancora una configurazione di integrazione continua ma trovo che funzioni bene per i siti Magento. Sentiti libero di inviarmi un messaggio se desideri altri consigli specifici per la tua configurazione.


1
è una vecchia risposta, ma spero che tu possa rispondere. 1 L'archiviazione della produzione local.xml non è un problema di sicurezza? 2 In quale fase e come si importa il database?
MployBy

5

Un altro metodo consiste nell'utilizzare la strategia di distribuzione della copia di hackathons magento, che in questo modo appare nel file composer.json:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

Utilizzando il metodo sopra riportato, i file installati vengono copiati dal fornitore nell'installazione effettiva, consentendone il commit in Git e la loro distribuzione come di consueto, senza dover eseguire alcuna installazione del compositore.

Non sono un grande fan di estrarre da repository di terze parti quando stai per eseguire una distribuzione live e dipendere da repository di terze parti è un po 'rischioso, a meno che tu non abbia una sorta di cache proxy per la tua rete .

Leggi questo articolo e ti darà una prospettiva diversa: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Fondamentalmente, l'NPM è andato giù (una specie di ...) e tutti i sistemi di build hanno smesso di funzionare (per distribuzioni critiche!) Perché dipendevano direttamente da NPM. (NPM è un po 'come Packagist per Javascript, tranne per il fatto che NPM ospita effettivamente il file e Packagist punta solo ai repository di moduli Github - correggimi se sbaglio)

modifica: solo la risposta di fschmengler rossa. Questa è un'elaborazione sul suo primo approccio


4

È importante capire che Composer non è uno strumento di distribuzione, ma uno strumento di sviluppo.

Esistono diversi approcci su come preparare una distribuzione con tutte le dipendenze:

  • esegue il commit della directory del fornitore (o ovunque compositore installi i sorgenti) nel repository del progetto
  • utilizzare un server di build che viene eseguito composer installe crea un archivio con il risultato, che è possibile distribuire ripetibile su diversi sistemi di destinazione
    • in esecuzione composer install sul server e quindi cambiare i collegamenti simbolici come suggerito da @ jharrison.au è una variante di questo

A parte questo, non consiglio di usare il compositore per ogni singolo modulo e conservare composer.jsone solo composer.lock nel repository del progetto. Questo sta esagerando e rende inutilmente complicato lo sviluppo. Ha perfettamente senso per il codice che viene riutilizzato in diversi progetti, ma perché inserire il codice specifico del progetto in repository separati?

La mia attuale struttura di progetto è simile a questa (usando gli installer di compositori alternativi di AOE ):

  • srccontiene tutti i moduli specifici del progetto. Composer installa anche qualsiasi altro modulo Magento qui
  • .modman collegamenti a src modo che modman possa gestire facilmente il collegamento simbolico
  • wwwè il webroot. Il compositore installa qui il core di Magento

In questo modo includo moduli esterni nel repository. Se preferisci non farlo, regolalo in questo modo:

  • srccontiene tutti i moduli specifici del progetto. Per includerli in .modmanmodo che modman crei collegamenti simbolici, utilizzaremodman link
  • .modmanè dentro .gitignore. Il compositore installa i moduli Magento qui
  • wwwè il webroot. Il compositore installa qui il core di Magento
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.