Flusso di lavoro di sviluppo per una squadra: locale da vivere (con GIT)

Question

Flusso di lavoro di sviluppo per una squadra: locale da vivere (con GIT)

#1 da (4 voti)

1

Stiamo cercando di mettere insieme un flusso di lavoro per lo sviluppo di Wordpress che risulta essere piuttosto complicato con molti elementi. C'è un modo per semplificare questo o riempire gli spazi vuoti?

Al momento abbiamo 2 sviluppatori nel team, ma in sostanza questo può essere comunque molti, tutti funzionano allo stesso modo.

I problemi

WP Stagecoach sembra l'unico modo per consentirci di unire un database piuttosto che copiarne solo uno. Qualcuno conosce altri metodi?

Lavoriamo su molti siti che necessitano della versione live per continuare a funzionare (e i dati vengono aggiornati) ... mentre si sviluppano nuove funzionalità (quindi entrambe le versioni si aggiungono alla tabella dei post nel database). Ciò solleva il problema della perdita di dati, della copia su alcuni ecc.

Il problema di Wp Stagecoach è che possiamo creare un sito di staging, apportare le modifiche lì, quindi unire di nuovo il sito live - quella parte funziona alla grande. Ma vogliamo essere in grado di lavorare localmente piuttosto che su un sito di staging (che HAS si trova sui server di Stagecoach).

Quindi la vera domanda è: come possiamo lavorare localmente su un sito e farlo live senza copiare dati live (cioè fondendoci con esso)? Fare i file è semplice, è il database che causa il problema.

git teamwork workflows wordpress

posta Rob 19.01.2016 - 17:09

fonte

1 risposta

Leggi altre domande sui tag git teamwork workflows wordpress

Qual è il nome corretto per questo oggetto dati? Fornisce un accesso utente come requisito funzionale di un sistema?

score 4 · Answer 1

Non ho mai lavorato con wordpress, ma ho lavorato su diverse applicazioni web che avevano un database, e il solito modo per rendere il database piacevole con il controllo del codice sorgente è usare un Schema Migration Framework .

L'idea è che ogni sviluppatore abbia un database di sviluppo personale installato sul proprio computer (o su un server personale o comunque si desideri lavorare) ma di solito si trova sul proprio computer perché non è necessario un server potente per database di sviluppo personale). Durante lo sviluppo, invece di modificare direttamente lo schema del database (e i dati della costante), si scrivono gli script di migrazione che eseguono queste modifiche. Questi script possono essere archiviati al controllo del codice sorgente e il framework di migrazione si occupa di eseguire gli script necessari nell'ordine corretto.

Ad esempio, invece di aggiungere una colonna a una tabella tramite la GUI di amministrazione del database, Rob con scriverà uno script di migrazione che lo farà e userà lo strumento di migrazione per eseguire quello script e aggiungere la colonna. Rob inserirà questo script nella base di codice, e quando Matt estrae le modifiche di Rob, prenderà anche quello script. Matt eseguirà quindi lo strumento di migrazione, che riconoscerà che il nuovo script non è ancora stato eseguito nel database di sviluppo personale di Matt e lo esegue.

Quando vuoi distribuire una nuova versione, usa semplicemente lo strumento di migrazione per eseguire tutti gli script aggiunti in questa versione sul database nell'area di staging della diligenza.