Ho un setup di cui sono abbastanza orgoglioso e funziona molto bene per il mio team.
Struttura generale
Tengo l'intera installazione sotto git. Tutte le modifiche, sia esso un aggiornamento del sistema, l'aggiunta / l'aggiornamento di un plug-in, l'aggiunta / l'aggiornamento di un tema, passano attraverso lo stesso flusso di lavoro. Le modifiche possono essere ripristinate in qualsiasi momento. Ho un server di distribuzione (un vecchio desktop P4) che esegue gitosis ma puoi usare github o gitolite con la stessa facilità . In git, ho due rami "speciali" mastere develop(spiegato più sotto). I miei server di produzione e gestione temporanea sono basati su cloud.
Ambienti di sviluppo
Ogni sviluppatore esegue il proprio server di sviluppo sul proprio computer. In termini di database, la necessità di dati live non è quasi mai stata un problema. Utilizziamo principalmente i dati di test dell'unità tematica . Altrimenti l'esportazione e l'importazione coprono la maggior parte delle cose. Se l'elemento DB era cruciale, è possibile impostare la replica o impostare qualcosa per la sincronizzazione su richiesta. Quando ho inizialmente impostato questa struttura, ho pensato che sarebbe stato cruciale, quindi ho iniziato a scrivere una serie di strumenti per farlo, ma con mia sorpresa non erano davvero necessari. (nota: dal momento che non erano necessari, non li ho mai ripuliti, quindi ci sono dei bug, ad esempio sostituirà il dominio nei dati serializzati).
Ambiente di gestione temporanea
Quando i commit vengono trasferiti dalla developfiliale alla gitosi, vengono automaticamente distribuiti sul nostro server di gestione temporanea. Il database di gestione temporanea è uno slave del database di produzione.
Ambiente di produzione
Quando i commit vengono spinti alla gitosi sul masterramo, viene automaticamente distribuito sul server di produzione.
Il problema di wp-config.php
Vuoi wp-config.phpessere unico da server a server, ma vuoi anche mantenerlo sotto il controllo della versione. La mia soluzione era quella di utilizzare .gitignoreper ignorare wp-config.phpe archiviare le versioni di gestione temporanea e di produzione come file con nomi diversi. Quindi su ogni server, ho symlink ad es wp-config.php -> wp-config-production.php. Ogni utente mantiene quindi il proprio DB con le proprie credenziali, con le proprie impostazioni (non tracciate) di wp-config.php.
Altre note
Uso Rackspace Cloud , che è fenomenale e poco costoso. Con esso posso mantenere identici i miei server di gestione temporanea e di produzione. Sto anche scrivendo plugin in questo momento che usano la loro API per permettermi di controllare i miei servizi direttamente da WordPress, è meraviglioso.
Le directory della cache, le directory di caricamento dei file, ecc., Vengono tutte aggiunte a .gitignore. Se lo desideri, puoi impostare un'attività cron per controllare regolarmente i caricamenti e portarli alla gitosi, ma non mi è mai sembrato necessario.
La struttura master / sviluppo è destinata a imitare parzialmente il modello di ramificazione di Vincent Driessen . Uso anche la sua estensione git git-flow e lo consiglio vivamente.
Ho avuto circa 10 sviluppatori che lavorano su questa struttura da oltre un anno ed è stato un sogno con cui lavorare. Affidabile, sicuro, veloce, funzionale e agile, non puoi chiedere di più!