Come si forniscono stime per l'aggiornamento di Magento?


63

Panoramica:

Questa domanda è stata originariamente posta e successivamente chiusa su StackOverflow . Abbiamo affermato in meta , che qui è il posto giusto per questa domanda.

Questa domanda è a favore di aiutare molte persone a trovare il modo corretto di stimare gli aggiornamenti di Magento.

La domanda:

Sono interessato a sapere come misurare il tempo necessario per l'aggiornamento di Magento? Immagino che la maggior parte di voi abbia avuto difficoltà a rispondere alla domanda del cliente: "Quanto tempo ci vorrà per aggiornare il mio negozio Magento?"

Di solito il cliente deve ascoltare solo un numero, ad esempio: "Ci vorranno X ore e costerà Y dollari".

L'idea principale alla base della domanda riguarda il lato tecnico e cosa controlli come sviluppatore per fare i tuoi calcoli per gli aggiornamenti di Magento.

Ho creato la prossima lista di controllo, solo per i miei calcoli:

  • Il nucleo di Magento è toccato?
  • Lo schema di Magento DB è stato toccato?
  • Abbiamo dati incoerenti nel DB?
  • Quante estensioni personalizzate sono installate nel pool di codici locale e della community?
  • Le estensioni personalizzate sono compatibili con l'ultima versione di Magento?
  • Lo sviluppatore del tema ha utilizzato il file local.xml per le direttive di layout o ha semplicemente copiato i file XML dalla base / default / layout alla directory di layout del tema personalizzato?
  • Abbiamo direttive di layout / metodi di blocco obsoleti nei file xml di layout?
  • Ho sviluppato questo negozio Magento?

Pensi che mi manchi qualcosa e, in caso affermativo, vorresti condividere con me e la community i tuoi punti aggiuntivi per l'elenco di controllo?


Per relativamente semplice ~ dallo 0,875 all'1,75% delle entrate annuali, per l'1,75% al ​​3,5% delle entrate annuali, per un difficile 2,625% al ​​5,25% delle entrate annuali.

Risposte:


100

La stima dell'aggiornamento di Magento è un processo di raccolta di informazioni sulle modifiche applicate all'installazione che si sta per aggiornare, verificando se tali modifiche possono causare un problema e quindi valutare quanto tempo è necessario per aggirarle.

Tutte le modifiche possono essere letteralmente divise in off-core e in-core .

Le modifiche off-core sono quelle che non verranno sovrascritte con l'aggiornamento. Queste sono estensioni di terze parti , file core messi in ambito locale (app / codice / local / Mage) e un tema personalizzato .

Le modifiche in-core vengono applicate direttamente ai file core di Magento (app / code / core), ai file di localizzazione (app / locale / en_US), ai modelli di base e ad alcune cose come javagram , librerie esterne che raramente vengono personalizzate, ma devono essere prese in considerazione .

Modifiche off-core

Estensioni di terze parti

Durante gli aggiornamenti, le estensioni di terze parti sono la principale fonte di problemi. Ciò significa che più estensioni hai più tempo necessario per analizzarle.

La prima cosa da verificare è se la funzionalità fornita dall'estensione non è ancora implementata in una versione di Magento a cui si sta eseguendo l'aggiornamento. Ad esempio alcune estensioni come Yoast_CanonicalUrl, Mxperts_CustomerAddresso Fontis_Wysiwygsono state ampiamente utilizzate in Magento 1.3.xx e precedenti, ma ora fanno parte delle funzionalità di base di Magento e non sono più necessarie.

Quindi è una buona idea controllare (chiedi al tuo cliente) se hai davvero bisogno di tutte quelle estensioni che hai. Potrebbero esserci alcune estensioni installate ma mai realmente utilizzate. Quindi a questo punto è bene fare una sorta di pulizia.

Quindi una cosa importante da verificare è la compatibilità di ciascuna delle rimanenti estensioni con una versione di Magento a cui stai eseguendo l'aggiornamento. Nel caso in cui alcune estensioni non siano compatibili e non siano disponibili estensioni simili, sarà difficile scegliere di perdere alcune funzionalità o modificare le estensioni esistenti per renderle compatibili.

Nota: non modificare direttamente l'estensione di terze parti, ma creare una nuova estensione che estenderà una obsoleta e quindi impostare una dipendenza in un XML bootstrap di nuova estensione.

Dopo tutto quello che è stato fatto, può essere fornita l'analisi effettiva di ciascuna delle rimanenti estensioni. Comincerà sempre con l'esame del etc/config.xmlfile. Ci sono 3 cose da cercare:

  • La riscrittura di classe non è una tecnica pulita da sola, ma in alcuni casi non c'è altro modo per aggirare. Quindi, se la classe riscritta fosse cambiata nella nuova versione di Magento, questo potrebbe essere un potenziale problema.
  • È molto probabile che gli aggiornamenti del layout causino un problema con l'aggiornamento, ma se l'estensione fa riferimento a un blocco deprecato in una versione più recente di Magento, dovrai risolvere il problema.
  • Gli aggiornamenti SQL sono fonte di problemi altamente sottovalutati durante gli aggiornamenti. Il problema si verifica quando l'estensione di terze parti sta creando una chiave esterna che fa riferimento a un campo nella tabella Magento predefinita. Di conseguenza questo campo è bloccato dalle modifiche. E poi se lo script di installazione nativo proverà ad aggiornare questo campo fallirà silenziosamente. Successivamente, ogni successivo script di installazione che fa riferimento a questo campo interromperà l'aggiornamento.

app / code / local / Mage

Dopo aver terminato con le estensioni è tempo di dare un'occhiata alla tua app/code/local/Magedirectory. Qui troverai i file core modificati spostati in un localambito. Ognuno di loro ti costerà sicuramente dei capelli grigi perché non sai mai (se non sei stato tu a metterli lì) cosa è stato modificato lì e per quale motivo. Quindi devi confrontare ciascuno di essi con un'origine e migrare le funzionalità aggiunte al file corrispondente della nuova versione.

Tema personalizzato

L'ultima modifica off-core del mazzo è il tema personalizzato. Questo potrebbe non sembrare un grosso problema, ma in realtà si tratta di un'area grigia. Il tema base di Magento viene modificato da una versione all'altra e ogni tema personalizzato deve imitare alcune di queste modifiche. Sfortunatamente non esiste un proiettile d'argento per determinare cosa cercare e cosa deve essere migrato. Quindi, preparati solo per alcune grandi sorprese e piccoli ritardi dopo l'aggiornamento.

Modifiche In-Core

Nel mondo perfetto non ce ne sono. Ma quando hai un'installazione di Magento dopo che è stata abusata da sviluppatori di terze parti, che offrono molto a buon mercato, puoi aspettarti qualsiasi cosa. Quindi le modifiche nel core sono quelle che verranno sovrascritte durante il processo di aggiornamento. Nella maggior parte dei casi non produrrà alcun errore ma di conseguenza perderete la funzionalità che è stata aggiunta in modo così brutale.

L'unico modo per rilevare le modifiche nel core è confrontare tutti i file dell'installazione di Magento con file puliti della stessa versione. Consiglio di farlo con Git. Perché? Semplicemente perché gestirà bene tutte le nuove linee e gli spazi bianchi.

Anche se l'installazione di Magento non è sotto git, puoi comunque copiare i tuoi file in una directory separata ed eseguire git init. Quindi esegui il commit iniziale, copia ed esegui i file Magento "puliti" git status. Otterrai qualcosa del genere:

Ora, a seconda del numero di file modificati, è possibile eseguire contemporaneamente git diffsu ciascun file o sull'intero batch. Ciò fornirà un riferimento completo di tutte le modifiche apportate al core. Se hai qualche visualizzazione git come phpStorm la vita è molto più facile per te:

Ti suggerisco di farlo git diff > changes.txt, avrai sempre un elenco di modifiche a mano.

Avendo l'elenco delle modifiche principali è possibile stimare cosa deve essere trasferito nella nuova versione e quanto tempo sarà necessario per farlo.

Ora vorrei dare alcuni consigli per un vero aggiornamento. Questo processo è ben documentato, quindi non scriverò quali comandi eseguire e dove fare clic. Tuttavia, voglio dare un accento su alcune cose importanti:

  • Partiamo dal presupposto che stai aggiornando nel tuo ambiente di sviluppo. Eseguire l'aggiornamento sul server di produzione è un suicidio.
  • Non lasciare che cambino nulla in produzione durante l'aggiornamento. Metti il ​​tuo Magento sotto controllo della versione o addirittura la scrittura di file di blocco temporanei.
  • Disabilita tutte le estensioni di terze parti, ma nota quali erano inizialmente disabilitate, quindi non le abiliterai in seguito.
  • Controlla se c'è uno script di pulizia Magento in esecuzione sul server. In caso contrario, troncare tutte le tabelle a partire da dataflow_*, log_*, report_*.
  • Ripristina il tema predefinito al momento dell'aggiornamento.

Dopo aver completato lo script di aggiornamento:

  • Facendo riferimento a ciò che changes.txthai fatto prima di migrare tutte le modifiche nel core che sono davvero degne di migrazione.
  • Migrare le app/code/local/Magemodifiche trovate prima dell'aggiornamento.
  • Uno a uno abilita le estensioni di terze parti.
  • Ripristina il tema e confronta in modo completo il risultato con il server di produzione.
  • Distribuisci in produzione una volta che sei soddisfatto del risultato.

Conclusione

So che tutto sembra spaventoso, ma se esegui l'aggiornamento regolarmente, mantieni pulito il tuo core e installi le estensioni solo da fornitori di cui ti fidi davvero e solo se ne hai davvero bisogno non dovrai affrontare la maggior parte delle difficoltà descritte in questo articolo. Mantieni sano il tuo Magento EcoSystem e sarai premiato.

Post scriptum

In casi molto complicati ha senso ricominciare da capo con una nuova installazione dell'ultimo Magento e migrare passo dopo passo il tema e la funzionalità del tuo negozio. Questo richiederà sicuramente tempo ma alla fine avrai un sistema Magento sano con la tua piena consapevolezza di ciò che sta succedendo.


Un altro modo per rilevare le modifiche nel core è usare il plugin Magento Project Mess Detector del n98-magerun .
Julien Loizelet,

15

In generale, il codice Core non dovrebbe mai essere toccato durante lo sviluppo. Ci sono molti meccanismi in Magento per permetterti di aggirare qualsiasi problema, anche i bug interni. Detto questo, ci sono anche altri problemi da tenere d'occhio.

  1. Qualsiasi modulo locale o locale ha la precedenza sul codice principale (può essere cercato nella cartella dei moduli <rewrite>, ed è una cattiva pratica in quanto dovrebbero davvero usare un codice non invadente come eventi)
  2. Magento tenta di mantenere il codice compatibile con le versioni precedenti, ma a volte il codice cambia in modo significativo ( può essere trovato qui ), se le modifiche all'indietro incompatibili sono molte, ciò potrebbe aggiungere al processo.
  3. È facile / possibile duplicare il codice in un ambiente di sviluppo. se lo è, semplicemente eseguire l'aggiornamento e il test potrebbe essere tutto ciò che è necessario.
  4. È necessario l'aggiornamento? Ci sono funzionalità nella nuova versione di cui il client non può uscire? Eventuali problemi di sicurezza (molte volte Magento fornisce anche back-patch)

Per quanto riguarda il modello, dall'esperienza precedente posso dirti che si rompe a malapena, a meno che lo sviluppatore non sia impazzito sulla codifica del modello (che dovrebbe essere comunque in blocchi).


10

Ecco alcune cose da tenere a mente:

  • Controlla se il tema è compatibile (controlla se esiste una codifica estesa nei file modello - a volte gli sviluppatori junior lo fanno)
  • Controlla come vengono archiviati i file multimediali (utilizzano CDN, ecc.)
  • Controlla se esistono metodi speciali di memorizzazione nella cache (APC Memcached ecc.)

Un modo per gestire questo tipo di richiesta client è quello di fare una revisione del preventivo.

Ciò implica dire al cliente che passerai un po 'di tempo (fatturabile) a guardarlo, e gli darà un periodo / costo più accurato per lo svolgimento del progetto.

Seguire questa strada è vantaggioso sia per te che per il cliente.

Il cliente di solito si sentirà più sicuro nel tuo preventivo e rispetterà i tuoi consigli, che a loro volta ti avvantaggiano, riducendo il possibile stress.

Stima recensione:

La revisione della stima effettiva sarebbe qualcosa del genere:

  • Scaricare il database live e importarlo su una macchina di sviluppo
  • Copia i file magento dalla loro macchina live alla tua macchina dev
  • Assicurati che tutto vada bene e funzioni
  • Tentare l'aggiornamento e fare alcuni test iniziali per vedere cosa potrebbe essersi rotto

Questo processo dovrebbe richiedere in media due ore fatturabili e ti fornirà tutte le informazioni necessarie sul sistema a portata di mano.


1
"Scarica il database live e importalo su una macchina di sviluppo": la conformità PCI è stata appena girata in testa. Assicurati di NON esportare le credenziali live ...
Luke A. Leber il

10

Abbiamo effettuato vari aggiornamenti su Magento CE, il peggiore è stato dall'1.3 all'1.7 e ci sono voluti quasi 4 giorni interi. La stima iniziale era di 1-2 giorni. Immagino che l'aggiornamento da 1.xa 2.x sarà un'impresa altrettanto grande e anche se gli strumenti di migrazione saranno forniti dal team principale, potrebbe essere più pulito iniziare da zero.


6

Voglio aggiungere una cosa alle risposte eccellenti fornite sopra:

  • Controllare se è presente un VCS e un processo di distribuzione corretto.

Non eseguirò un aggiornamento senza i processi adeguati dietro e la possibilità di fare un passo indietro quando si verificano problemi (ancora di più se non avessi lavorato sul sito prima). Circa il 90% dei clienti che si avvicinano a noi per un aggiornamento di Magento (che non sono mai stati nostri clienti prima) hanno solo un ambiente live senza alcun test / messa in scena, VCS di sorta.


6

L'integrazione con altre entità è una cosa importante di cui chiedere. Questo è qualcosa che potresti non essere in grado di individuare guardando il sito: è comune per i client avere sistemi back-end che raccolgono ordini tramite l'API Magento, ad esempio, e se non gestisci la continuità di tale integrazione durante l'aggiornamento può fare casino.

Quando si esaminano i componenti, cercare quelli che parlano con altri sistemi: ognuno di questi sarà peloso da testare perché non si desidera trasferire accidentalmente i dati di test su un sistema attivo. Spesso esiste un endpoint di test utilizzato dagli sviluppatori originali, ma potresti non avere più tali informazioni durante l'aggiornamento.


Grazie, è qualcosa che non ho mai visto finora, ma è bello saperlo!
ceckoslab,
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.