Sviluppare con wordpress in tranquillità – Il workflow

Tempo di riordinare un po’ l’ambiente di .
Per adesso l’obiettivo principale è poter sviluppare in tranquillità siti in wordpress. Unica complicazione: anche il mio collega grafico deve poter effettuare modifiche.
L’ultimo sito che abbiamo sviluppato insieme era ospitato in un vps su amazon ec2 a cui erano stati puntati dei dns di terzo livello da un mio dominio (i2media.it).
Io, occupandomi dello sviluppo php (presto un articolo su quanto faccia schifo wordpress), eseguivo gli update con git, il grafico faceva tutto tramite ftp (poiché MAI riuscirebbe a capire come usare git, per di più da un mac).
Oltre a ciò, io in locale non avevo alcun ambiente di sviluppo, quindi ogni riga di modificata richiedeva un commit.
Insomma, una selva di varie centinaia di commit a settimana, aggiornamenti mezzi persi sul server, per due volte ho dovuto ricostruire a mano tutto il repository git, un disastro.

Ora invece è giunto il momento di migliorare e di metter su un vero ambiente di sviluppo.

Il Workflow

workflow

Le modifiche in locale sono sincronizzate tra pc e server. Solo le Release Candidate vengono pubblicate sul server remoto.

 

Sul pc locale eseguo lo sviluppo vero e proprio, quando c’è qualcosa che effettivamente funziona faccio l’update sul server locale.

Il server locale sarà accessibile dall’esterno, così da poter lavorare in remoto e permettere al grafico di effettuare modifiche al template tramite ftp.
Ora la questione complicata: pc e server dovranno mantenere allineati i file e le versioni del database. Tutto ciò in maniera più trasparente possibile e senza intoppi.
Non voglio più ritrovarmi nella condizione di buttare via un giorno di lavoro poiché ho lavorato su un file che è stato modificato a mia insaputa sul server (normalente style.css, che con wordpress diventa una fogna).

Su internet si trovano vari metodi ma nessuno realmente completo. In generale tutti si basano sull’uso degli hooks di git.
Molto interessante è l’uso di mysqldump con git per effettuare il backup del database.
Dovrò fare varie prove per far funzionare il tutto, seguirà sicuramente un articolo a riguardo.

Il server pubblico deve servire solamente da presentazione di una Release Candidate; non è previsto farci modifiche.
Però si pone il problema: come identificare una release candidate? Come fare il deploy sul server (visto che serve anche il db) ?

Infine servirà un sistema automatico di deploy di un nuovo sito (magari con fabric ).

Leave a Reply