Automatizzare lo sviluppo e l'implementazione di Wordpress

Question

Qualcuno ha mai lavorato a un progetto WordPress con più sviluppatori in luoghi diversi? Esistono best practice in merito ai team di sviluppo distribuiti e alle distribuzioni automatizzate?

Ho un team di diversi gradi di sviluppatori, inclusi sviluppatori di plug-in, sviluppatori di temi e semplici tweakers in stile CSS, in alcune posizioni diverse, e mi piacerebbe impostare un buon sistema per consentire a tutti di lavorare su i loro pezzi separati e distribuiscono continuamente le modifiche senza disturbare il codice di qualcun altro.

Al momento il sistema esegue un'installazione di WordPress-MU e alla fine verrà aggiornato a 3.0. Idealmente, dovremmo archiviare i temi e i plugin nel controllo del codice sorgente, e poiché alcune modifiche sono state apportate al codice core di WordPress, deve entrare nel repository. Ho difficoltà a capire il modo migliore per strutturare il repository e fare distribuzioni controllate ma alquanto automatizzate.

Come gestite il lavoro e la distribuzione negli ambienti di sviluppo, testing, staging e produzione, quando diversi tipi di plug-in e temi possono memorizzare configurazioni nel file system o nel database? Mi rendo conto che la risposta potrebbe essere "Non utilizzare WordPress," ma assumendo devo, fatemi sapere cosa ne pensate,

Grazie per il vostro aiuto,

Dave

Answer 1

Ecco come ho finito per risolvere questo problema finora:

directory di codice sorgente:

build/ - build files for phing and environment-specific properties files 
    build.xml 
    src_qa.properties - properties to use the qa server as the source for a deployment 
    dst_qa.properties - properties to use the qa server as the destination for a deployment 
    etc... for other environments 
conf/ - contains environment specific configuration files, each in a subfolder named after the environment 
    dev/ 
     db-config.php - config file for HyperDB - http://codex.wordpress.org/HyperDB 
     default - Apache conf that holds ServerAlias configs for multi-site WordPress 
     hosts - useful for developers to redirect their browser to various domains in different environments 
     htaccess.dist - for WPMU 
     httpd.conf - main Apache config file, specific to each environment 
     my.cnf - mysql config file 
     wp-config.php - main wordpress config file 
    qa 
     (same as dev/ but with different values in each file) 
    staging 
     (same as dev/ but with different values in each file) 
    prod 
     (same as dev/ but with different values in each file) 
src/ - wordpress source code 
    wp-admin/ 
    wp-content/ 
     mu-plugins/ 
     plugins/ 
     themes/ 
    wp-includes/ 
test/ - holds WP test suite and custom tests for plugins, themes, etc... 

sto usando Hudson CI Server (http://hudson-ci.org/) per per automatizzata e manuale costruisce utilizzando attività sovversione checkout , phing, phpunit, ecc ... In sostanza, il server Hudson estrae il codice dalla sovversione a seconda di ciò che si desidera distribuire e rsync i file da distribuire dal server CI al server di destinazione.

Oppure, nel caso di un'implementazione dalla gestione diretta alla produzione, Hudson esegue il rsync dei file dalla gestione temporanea, fino al server CI e quindi il backup in produzione.

devo costruire l'installazione di posti di lavoro a Hudson per le seguenti parti di funzionalità:

core WP code - deploys core WP files and mu-plugins from src to dst 
    svn to qa 
    svn to staging 
    staging to prod 
WP plugins/ folder - deploys only the plugins folder 
    svn to qa 
    svn to staging 
    staging to prod 
WP themes/ folder - deploys the entire themes folder 
    svn to qa 
    svn to staging 
    svn to prod 
Specific themes - deploys a specific theme (chosen through a drop down during the build process using Hudson's parameterized build feature - http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build) 
    svn to qa 
    svn to staging 
    svn to prod 

I lavori Hudson hanno anche la possibilità di distribuire i file PHP specifiche ambientali (ad esempio wp-config.php, db-config. php), così come i file di configurazione di Apache e MySQL nelle posizioni corrette su ciascun server. In alcuni casi, utilizziamo più server Web e più server di database e la maggior parte della configurazione di build viene gestita tramite il file di sviluppo phing e i file .properties citati sopra.

In futuro, quando disponiamo di un ambiente di integrazione di sviluppo, eseguiremo probabilmente implementazioni automatizzate dopo il controllo svn di qualsiasi codice.

Questa configurazione consente agli sviluppatori differenti nell'organizzazione con diverse qualifiche (CSS/HTML vs PHP principalmente) di lavorare separatamente e ottenere il loro codice cambia fuori agli ambienti adeguati in fretta senza coinvolgere un gruppo di persone inutili. Hudson mi consente di bloccare diversi lavori di distribuzione in modo che solo le persone giuste abbiano accesso per configurarli e dargli il via.

Questa è una panoramica di alto livello di ciò che ho impostato, fatemi sapere cosa ne pensate. I maggiori fastidi con questa configurazione sono stati keypairs, account utente e autorizzazioni file con rsync su tutti i diversi server.

Dave

Answer 2

per il filesystem che usiamo GIT e funziona molto bene. Puoi avere un ramo per ogni membro del team e quindi unirlo nel ramo di produzione. Possiamo mantenere il nostro codice integrato senza problemi.

Per il database continuo a scaricare il database prod e a condividerlo con tutti (puoi persino inviarlo al repository GIT e poi tutti avranno l'ultimo dump).