Deployment per Siti WordPress in Ambiente Dev, Stage e Production?

Ho una configurazione di cui sono piuttosto orgoglioso e che funziona estremamente bene per il mio team.

Struttura Generale

Mantengo l'intera installazione sotto git. Tutte le modifiche, che si tratti di un aggiornamento di sistema, aggiunta/aggiornamento di un plugin, aggiunta/aggiornamento di un tema, seguono lo stesso flusso di lavoro. Le modifiche possono essere annullate in un attimo. Ho un server di deployment (un vecchio desktop P4) che esegue gitosis ma potresti altrettanto facilmente usare github o gitolite. In git, ho due branch "speciali", master e develop (spiegati più avanti). I miei server di produzione e staging sono basati su cloud.

Ambienti di Sviluppo

Ogni sviluppatore esegue il proprio server di sviluppo sulla propria macchina. In termini di database, raramente abbiamo avuto bisogno di dati live. Utilizziamo principalmente i dati di test del tema unit. Altrimenti, l'export e l'import coprono la maggior parte delle esigenze. Se il pezzo del DB fosse cruciale, potresti configurare la replica o impostare qualcosa per la sincronizzazione su richiesta. Quando ho inizialmente configurato questa struttura, pensavo che questo sarebbe stato cruciale, quindi ho iniziato a scrivere un set di strumenti per farlo, ma con mia sorpresa non erano davvero necessari. (nota: poiché non erano necessari, non li ho mai perfezionati, quindi ci sono bug, ad esempio sostituirà il dominio nei dati serializzati).

Ambiente di Staging

Quando i commit vengono inviati dal branch develop a gitosis, vengono automaticamente distribuiti sul nostro server di staging. Il database di staging è uno slave del database di produzione.

Ambiente di Produzione

Quando i commit vengono inviati a gitosis sul branch master, vengono automaticamente distribuiti sul server di produzione.

Il problema di wp-config.php

Vuoi che wp-config.php sia unico da server a server, ma vuoi anche tenerlo sotto controllo di versione. La mia soluzione è stata usare .gitignore per ignorare wp-config.php e memorizzare le versioni di staging e produzione come file con nomi diversi. Quindi su ogni server, creo un symlink, ad esempio 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 ed economico. Con esso posso mantenere i miei server di staging e produzione identici. Sto anche scrivendo plugin che utilizzano la loro API per permettermi di controllare i miei servizi direttamente da WordPress, è fantastico.

Le directory della cache, le directory di upload dei file, ecc., sono tutte aggiunte a .gitignore. Se volessi, potresti impostare un'attività cron per verificare periodicamente gli upload e inviarli a gitosis, ma non è mai sembrato necessario.

La struttura master/develop è impostata per imitare parzialmente il modello di branching di Vincent Driessen. Uso anche la sua estensione git git-flow e la consiglio vivamente.

Ho avuto circa 10 sviluppatori che lavorano con questa struttura per oltre un anno ed è stato un sogno lavorarci. Affidabile, sicuro, veloce, funzionale e agile, non si può chiedere di meglio!

Innanzitutto, penso sia importante considerare cosa si intende mettere sotto controllo di versione. Raccomando contro l'idea di mettere l'intera directory di WP sotto VC. Ritengo che abbia più senso mettere sotto controllo wp-content/themes/NomeDelTuoTema. Per un sito ampio con un numero elevato di plugin complessi, si potrebbe considerare di includere anche wp-content/plugins. Se fosse assolutamente necessario, si potrebbe includere wp-content/uploads. Le risposte seguenti cambieranno leggermente, a seconda di cosa si decide di versionare.

Detto questo, ecco cosa utilizzo io:

Locale: Configurare un ambiente LAMP sulla tua macchina. Utilizza lo stesso URL del tuo sito di sviluppo. Usa VirtualHosts e voci nel file .host per simulare l'ambiente di sviluppo dal punto di vista dell'URL. Se stai versionando solo il tuo tema, considera l'uso di SSHFS per collegarti a wp-content/plugins, wp-content/uploads. Considera l'uso del database della tua installazione di sviluppo del progetto, a meno che tu non stia facendo operazioni particolarmente complesse.

Sviluppo: Estrai una copia di lavoro del tuo repository nel tuo ambiente WP. Configura un Hook POST-COMMIT in SVN per aggiornare questo repo ad ogni commit. Questo lo manterrà sincronizzato. (Consideralo una forma rudimentale di integrazione continua.)

Produzione: Estrai un tag di versione nominato che rappresenta una versione candidata finale. Quando devi utilizzare una nuova versione, cambia il tag e aggiorna il repository.

Abbiamo recentemente scoperto RAMP. Nota: questa è solo una parte dell'intero processo, ma la sincronizzazione dei database dei contenuti tra i server è probabilmente la parte più complessa.

Lo faccio con git e mercurial, assicurati solo di utilizzare un repository privato.

Opzione 1.

L'unico problema è il config.php, che puoi dire a git di ignorare durante il push o prima dell'inizializzazione.

Usa .gitignore oppure git update-index --assume-unchanged config.php (leggi un po' riguardo al comando assumed-unchanged prima di usarlo)

Opzione 2.

Usa un condizionale nel config.php che controlla l'url e applica le credenziali corrette, qualcosa come "se l'url del server = dev allora usa le credenziali A, altrimenti usa le credenziali B", ecc.

Mark lo spiega meglio, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

PS. Puoi anche servire i file direttamente da un repository remoto invece di avere un tradizionale "file server". (video veramente noioso che ho fatto su questo http://www.youtube.com/watch?v=8ZEiFi4thDI)