Come faccio ad aggiungere il controllo versione al mio flusso di lavoro?


11

Sviluppo temi, molti. Mi viene dato un PSD, codifico HTML / CSS, schiaffo il codice in Wordpress ed eseguo correzioni man mano che ottengono il controllo qualità. Una volta in diretta, i clienti possono modificare i post del blog come al solito o caricare foto utilizzando un plug-in personalizzato.

A volte devo apportare modifiche al tema o al contenuto della pagina / post, il che significa che li faccio vivere o devo scaricare e configurare il sito in un ambiente di sviluppo per essere approvato dal client. Non ho backup, non ho controllo di versione e mi rendo conto che questo deve cambiare.

Sono stati suggeriti Git e Mercurial e vorrei sfruttare questi strumenti, ma sono confuso su come inserirli in un flusso di lavoro.

Devo richiedere tutte le modifiche a un sito su un server di sviluppo e quindi inviarle dal vivo una volta approvate? Che dire di scrivere post sul blog? Sembra eccessivo scrivere post su dev e inviare modifiche in tempo reale, ma come faccio a sincronizzare i database se vengono modificati sul sito live? Ho setacciato Internet. Qualche consiglio sarebbe apprezzato.


Penso che questo si qualifichi come una domanda ecosistemica fuori campo. Vedi qui per discussioni in corso .
Chip Bennett,

4
@ChipBennett Non sono d'accordo. Le dipendenze specifiche di WordPress tra temi, plugin e database e il modo in cui influenzano la pratica generale degli sviluppatori sono benvenute.
fuxia

@toscho Potrei sicuramente esserne convinto; ecco perché ho indicato la discussione Meta. :)
Chip Bennett,

Risposte:


9

Prima di tutto, devi riconoscere che ci sono due flussi di lavoro qui: il tuo e il tuo cliente.

Il tuo flusso di lavoro

  • Ricevi PSD
  • Codice HTML / CSS
  • Codice modello WordPress
  • Distribuisci tema per vivere il sito WordPress

Il loro flusso di lavoro

  • Elaborare le modifiche necessarie e inviarti un'e-mail
  • Scrivi post
  • Caricare foto

Il problema

L'implementazione del controllo versione qui non ha assolutamente nulla a che fare con il flusso di lavoro dei tuoi clienti. Si tratta di tenere traccia del codice che si utilizza per il tema WordPress. Tutti i file dei temi, i plug-in personalizzati, ecc. Dovrebbero essere in un sistema di controllo della versione (Git, Mercurial, Subversion o qualunque cosa tu scelga di usare).

Il flusso di lavoro diventa quindi:

  • Scrivi il codice
  • Apporta modifiche al sistema di controllo della versione
  • Invia modifiche al sito di produzione
  • Ricevi commenti dal client
  • Scrivi il codice
  • Effettua modifiche
  • Scrivi il codice
  • Effettua modifiche
  • Invia modifiche al sito di produzione

Ricorda, si tratta di mantenere una cronologia di controllo versione per il tuo codice . Il codice è qualcosa che i tuoi clienti non dovrebbero cambiare - e non dovresti mai cambiare il codice in un sito di produzione mentre è in produzione.

Ma le modifiche al contenuto (post, foto, ecc.) Non rientrano nell'ambito del sistema di controllo della versione. In altre parole, non si apportano modifiche allo sviluppo e quindi si spinge il database in produzione. Questa è una cattiva pratica di sviluppo. Se è necessario che i database dev e prod siano sincronizzati, è necessario estrarre regolarmente un backup dalla casella di produzione e ripristinare la versione locale da quel backup.

Le modifiche al codice fluiscono dallo sviluppo alla produzione.
Il database cambia flusso dalla produzione allo sviluppo.


Non puoi davvero sincronizzare facilmente i database a meno che tu non abbia uno script speciale che gestisca il modo in cui i dati del contenuto sono archiviati nel database. Ecco perché separi il codice dal contenuto del tuo flusso di lavoro, l'alternativa è utilizzare un server di gestione temporanea o provare a utilizzare uno degli script di sincronizzazione db o scrivere il tuo.
Wyck,

@EAMann Ottima risposta, grazie! L'unica cosa che aggiungerei al flusso di lavoro che hai descritto sarebbe scrivere codice, eseguire il commit delle modifiche, spingere nel sito di sviluppo, ottenere commenti dal client, ... Non avevo considerato due flussi di lavoro separati perché regolarmente dovremmo cambiare il accontentarsi dei clienti. Occasionalmente dovremo inserire HTML nel contenuto per soddisfare richieste speciali all'interno del contenuto (stili speciali, ecc.). A volte richiedono l'approvazione del client prima di essere pubblicati, motivo per cui i database dovrebbero essere sincronizzati. Esistono best practice per questo tipo di installazione?
cfr.

@Wyck Piuttosto che far cadere il contenuto insieme al tema, ha senso separare i due processi. Mi piace l'idea di un'area di sviluppo per i temi e un'area di gestione temporanea per la caduta di contenuti indipendenti l'una dall'altra. L'unico problema che vedo è che ai clienti piace vedere sia il tema che il contenuto (il sito nella sua interezza; pagine statiche) prima di lanciarlo dal vivo.
cfr.

Di solito non si tratta di sincronizzare le modifiche al database. Quello che intendevo dire è che prendi un dump del tuo database di produzione e sostituisci il tuo database di sviluppo locale con esso. È vero, puoi automatizzarlo con uno script ... ma probabilmente non lo farai molto spesso.
EAMann,

3
Non c'è ancora, è davvero una spina nel fianco di WordPress ma non è un problema specifico di WordPress poiché molti CMS hanno questo problema, puoi leggerlo qui wordpress.stackexchange.com/questions/119/… più in profondità, alcuni gli script esistono là fuori ma la maggior parte sono in casa perché sono specifici di un determinato ambiente.
Wyck,

1

È possibile utilizzare il software che sincronizza i database. Ma c'è anche l'opzione di versionare i dati stessi con qualcosa come http://chronicdb.com


Questo sembra interessante; potrebbe risolvere alcuni dei problemi. Lo controllerò, grazie.
cfr.

1

Ho appena scritto una risposta esauriente a questa domanda su un'altra domanda. Personalmente uso git ed è fantastico. Per iniziare, ti consiglio di visitare http://gitref.org/ e http://help.github.com/mac-set-up-git/ . Se sei il tipo di libro, ho letto questo e vale sicuramente il prezzo di ebook $ 22. Fallo fare, non ti pentirai di quella decisione.


Grazie, dovrò fare riferimento ad esso. L'impostazione del database master / slave sembra interessante. Grazie per la guida
cfr.
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.