Qual è la migliore strategia di implementazione?

82

La creazione di un negozio Magento non è solo una questione di sviluppo di estensioni autoinstallabili ma richiede anche molte operazioni di "inserimento manuale" come la creazione di attributi di modifica finale, categorie, prodotti, pagine CMS di regole di prezzo e così via, per non parlare di tutto le modifiche alla configurazione del sistema.

Vorrei che il tuo aiuto definisse la migliore strategia quando si tratta di distribuire un negozio Magento dallo sviluppo all'ambiente di gestione temporanea e di produzione.

Una mia strategia è quella di scrivere un "modulo di distribuzione" che crei programmaticamente le entità sopra menzionate, ma è un compito che richiede molto tempo e talvolta mi sembra un po 'eccessivo.

Di recente ho iniziato a utilizzare Selenium IDE per riprodurre le attività di amministrazione, ma il tempo necessario per impostare tutte le suite di test non è lontano da quello sopra menzionato.

Forse una soluzione ottimale potrebbe essere l'uso di un modulo in grado di fare un'istantanea di un sistema Magento che ti consente di scegliere cosa distribuire.

Così:

qual è la tua strategia di distribuzione?
esiste un modulo in grado di fare un'istantanea di un sistema Magento che ti consente di scegliere cosa distribuire?
se tale modulo non esiste e purché tale modulo sia una soluzione ragionevole, c'è qualcuno interessato a dare il proprio contributo per svilupparlo?

Grazie!

deploy admin entities

— Alessandro Ronchi
fonte

Ciò potrebbe indicare la necessità di un altro tag o categoria di tag. Sei un negozio unico o stai cercando suggerimenti generali come fornitore di servizi? In quest'ultimo caso, ogni risposta dovrebbe essere contrassegnata con "dipende da quanto controllo il cliente desidera sui dati dell'entità".

— benmarks

Il mio punto di vista è quello di uno sviluppatore appartenente a un team di sviluppo. Supponiamo che stia sviluppando una sezione che necessita di alcuni dati per funzionare, diciamo una struttura di categorie. Creo la struttura tramite Admin, eseguo il codice e invio il mio codice. Mi chiedo se la migliore strategia sia anche quella di scrivere e spingere codice che crei la struttura di categoria necessaria. Che cosa succede se la struttura della mia categoria o le impostazioni sono in conflitto con quelle di altri sviluppatori che ne hanno spinto le proprie? Come gestisco i conflitti? Questo è il mio punto.

— Alessandro Ronchi,

@AlessandroRonchi Questo è un punto controverso e un conflitto che non dovrebbe mai accadere. La struttura della tua categoria non è qualcosa che dovrebbe cambiare in modo frivolo, quindi uno sviluppatore non dovrebbe spingere un cambiamento sostanziale nella tua struttura, senza che gli altri lo sappiano. Se ciò accade, è necessario rivolgersi alla comunicazione inter-sviluppo. Generalmente la struttura delle categorie di un sito deve essere bloccata dal primo giorno e non è più necessario cambiarla, basta aggiungerla. Se è necessario modificarlo, la prima volta non è stato eseguito correttamente l'ambito.

— ProxiBlue,

@dedmeet purtroppo, nel mondo che conosco e lavoro, le cose cambiano ogni giorno; i clienti cambiano idea, gli sviluppatori cambiano idea, si verificano cigni neri. Devo essere pronto ai cambiamenti; comunque, anche se la struttura delle categorie non ha bisogno di essere cambiata dal primo giorno, è solo una piccola parte dell'intera parte e l'intera parte è un progetto "work in progress" che dovrebbe cambiare per fare le cose.

— Alessandro Ronchi,

ok, scontato, lavoriamo in un ambiente in continua evoluzione, ma continuo a sostenere che un conflitto di struttura di categoria non dovrebbe accadere. Non dovrebbero esistere più rami in cui ognuno cambia la struttura, il che porterà solo a problemi e alla perdita di tempo di sviluppo. Perché dev è un tempo che trascorre facendo cambiamenti alla struttura, mentre dev b sta facendo lo stesso, in una struttura diversa, ed entrambi spingono il loro lavoro? Se la struttura deve cambiare, tutti gli sviluppatori coinvolti nel progetto devono essere coinvolti nel processo di definizione della nuova struttura. Potete fornire un esempio per aiutarmi a capire quando ciò può accadere?

— ProxiBlue,

39

La mia opinione è di scrivere tutto. Di solito ho un modulo di configurazione di base per tutto ciò che non è direttamente correlato a uno specifico modulo funzionalmente. (ad esempio la creazione di riscrizioni di URL personalizzati per l'URL del sito precedente nel nuovo URL del sito) e aggiungere qualsiasi elemento relativo a un modulo ai propri script di installazione.

La mentalità dietro questo è che se il sito deve essere reinstallato, usando un nuovo db, allora tutto ritorna come lo avevi. Questo aiuta anche nel fatto che aggiorno periodicamente il sito Web con una copia del db live. I moduli in uat continuano quindi a funzionare mentre si inseriscono nuovamente nelle loro configurazioni.

Le modifiche alle tariffe postali, alle regole del carrello, ecc. (In pratica le cose che i clienti gestiscono da sole in amministrazione) sono considerate "dati volatili" e non sono scritte. Ciò include i dati di prodotto. Il cliente ha l'opzione ed è incoraggiato a testare prima le nuove importazioni sul sito Uat.

Ai clienti viene detto di non creare attributi, ma piuttosto di crearli tramite una richiesta di ticket. Ciò mi consente quindi di raccogliere anche informazioni sull'intenzione dei clienti per l'attributo e, a volte, ho un suggerimento migliore o posso creare un codice migliore poiché ho un controllo su quali attributi esistono, più su attributi selezionabili, assicurandomi che i dati siano pulito.

Sì, lo scripting richiede più tempo, ma ci vorrà molto più tempo per ricreare manualmente le impostazioni di configurazione di interi siti in un secondo momento. Può anche essere imbarazzante se si dimentica qualcosa e si fa in modo che il sito non funzioni correttamente o se un nuovo sviluppatore funziona su un sito locale in cui manca una configurazione di configurazione cruciale.

— ProxiBlue
fonte

1

Sono d'accordo con dedmeet. Quando impari come script di tutti gli aggiornamenti per la prima volta, potrebbe essere più un lavoro iniziale ma se devi applicare manualmente gli aggiornamenti di configurazione per 3-4 sviluppatori, staging, uat e live, il coordinamento e il lavoro effettivo impiegheranno molto più tempo. Il nostro flusso di lavoro è abbastanza simile: se la configurazione è necessaria per un'estensione (riutilizzabile), mettila lì. Se la configurazione è specifica del client, inserirla in un'estensione specifica del progetto. Una delle poche eccezioni sono le regole del carrello che non sono affatto divertenti da aggiornare / creare.

— Matthias Zeis,

1

Ho appena rilasciato un modulo che aiuta a creare lo script di configurazione richiesto, eliminando così il banale lavoro di dover creare manualmente gli script di installazione. Il modulo utilizza una visualizzazione a griglia della tabella core_config_data per consentire l'esportazione delle selezioni dei valori di configurazione. Rendi la mia vita un po 'più semplice e spero che funzionerà per gli altri. proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

27

Sono stato alcune ricerche diversi mesi fa. Ecco i siti a cui puoi fare riferimento.

~~Magento Base URL e installazioni di~~
sviluppo ~~/ staging~~ Magento Sviluppo e distribuzione
Magento Guida Git e flusso di lavoro Dump
più rapido di un database MySQL Magento per Branching

— Oğuz Çelikdemir
fonte

1

Grazie, li leggerò tutti e tornerò con alcune considerazioni.

— Alessandro Ronchi,

Ho letto tutto dare risorse; Ne conoscevo già alcuni, altri che non conoscevo sono molto interessanti. Nessuno di loro, comunque, è la soluzione al mio problema e ho deciso di delineare un'estensione che cercherà di soddisfare le mie esigenze. Grazie a tutti voi che mi avete dato preziosi consigli. Spero di tornare qui con alcuni risultati.

— Alessandro Ronchi,

Caro Alessandro, mi piacerebbe vedere a modo tuo che sto cercando anche una tecnica più comoda!

— Oğuz Çelikdemir,

18

Vorrei ringraziare tutti voi perché le vostre considerazioni mi hanno ispirato e mi hanno spinto a sviluppare un'estensione, chiamata "Mageploy" con l'intento di risolvere il problema di mantenere diversi ambienti in sincronia.

http://www.mageploy.com

Mageploy deve ancora essere esteso, ben documentato e completamente testato anche se lo sto già utilizzando in un paio di progetti con alcuni vantaggi.

È open source e qualsiasi aiuto o suggerimento sarà apprezzato.

Saluti

— Alessandro Ronchi
fonte

7

Per quanto riguarda gli script di installazione e la creazione di entità, la mia sensazione generale è che se è richiesto o previsto da un modulo, dovrebbe essere creato come parte di uno script di installazione.

Di recente, in termini di sviluppo / fase / produzione, utilizziamo il sito di gestione temporanea come copia principale del database per i contenuti in quanto ciò significa che il cliente può collaborare. In passato, probabilmente il problema più grande che abbiamo riscontrato è il coordinamento della voce di contenuto con il cliente, in particolare per quanto riguarda il caricamento del prodotto.

Come pensavi che avrebbe funzionato l'istantanea? Penso che in un mondo ideale, avresti uno strumento che mostrava la differenza tra due database su tipi particolari (prodotti, categorie, CMS ecc.) E ti permetteva di unire le modifiche l'una con l'altra, ma non sono a conoscenza di nulla di simile come quello.

— Paolo
fonte

1

"Per quanto riguarda gli script di installazione e la creazione di entità, la mia sensazione generale è che se è richiesto o previsto da un modulo, dovrebbe essere creato come parte di uno script di installazione." Questo è il punto più saliente da considerare e si applica alle impostazioni di configurazione. Il mio test rapido: quando ho bisogno di un nuovo sviluppatore per clonare il repository e installare l'ambiente, cosa deve esistere per far funzionare il sistema?

— benmarks

La condivisione di un sito di staging con i clienti per collaborare alla configurazione è ottima in teoria. In pratica, i clienti non ti dicono tutto ciò che hanno cambiato il 99% delle volte, il che rende facile rovinare qualcosa. Potremmo consentire ai clienti di lavorare su cose come regole del carrello, categorie, prodotti o simili, ma non lasciamo che interferiscano con la configurazione.

— Matthias Zeis,

6

A mio avviso, la creazione e la modifica di attributi, categorie, prodotti, regole dei prezzi non hanno nulla a che fare con una "strategia di distribuzione" Tutti questi articoli sono piuttosto unici per un negozio e nella maggior parte dei casi richiedono un po 'di analisi e ricerca dei prodotti venderemo.

Se stai creando negozi "taglia unica" con una configurazione simile di tutti gli elementi che menzioni, potresti semplicemente effettuare un'esportazione "istantanea" del tuo database dopo aver eseguito tutte le impostazioni necessarie per ogni negozio.

— Rutger
fonte

No, "una taglia si adatta a tutti" non è il punto; è la stessa situazione in cui, come sviluppatori, arriviamo quando è il momento di unire il nostro codice sorgente con quello di un altro membro del team di sviluppo: in quel caso abbiamo sistemi di controllo del codice che fanno la magia. La mia domanda era più legata all'opportunità di unire elementi "non dev" come impostazioni di configurazione e voci e voci di amministrazione tipiche.

— Alessandro Ronchi,

Ah ok, questo lo rende più chiaro

— Rutger,

Diciamo che stiamo creando un nuovo sito Web completo, quindi nessun problema con i vecchi dati ecc. Quasi sempre tutti i nostri sviluppatori usano lo stesso database per lo sviluppo. Ciò risolve molti problemi. Per altri casi non ho una soluzione migliore (ancora) che scrivere tutti i passaggi necessari in una sorta di roadmap / script e riapplicarli tutti dopo la fusione. Se solo una persona è responsabile delle impostazioni dell'amministratore "core magento", ciò non dovrebbe comportare molti passaggi. Una volta l'ho trovato, ma non l'ho mai provato tinybrick.com/magento-modules/admin-tools/…

— Rutger,

2

Vorrei aggiungere due eccellenti strumenti per risparmiare tempo:

Per lo sviluppo: PhpStorm IDE con il plug-in Magicento
Per la distribuzione: Magentify , una ricetta Capistrano per Magento

— osondoar
fonte

Grazie per averci informato di Magentify, non lo sapevo e lo proverò. La mia attenzione, tuttavia, era più sulla sincronizzazione di diversi ambienti di sviluppo che sulla distribuzione nel senso di pubblicare una base di codice. Mageploy potrebbe essere integrato con Magentify ma è uno strumento diverso, utilizzato per mantenere automaticamente allineate alcune parti delle modifiche al database indipendentemente da ID specifici che differiscono tra i diversi ambienti. Cordiali saluti, Alessandro

— Alessandro Ronchi