Non c'è tempo per scrivere una risposta completa (conosco una specie di zoppo) ma probabilmente vale la pena condividerla comunque (potrei modificarlo perché pianifico un post sul blog anche su questo):
Ciò significa che puoi avere una configurazione WP basata su trunk / versione-ramo che puoi hackerare completamente incl. temi e plugin.
Poiché si tratta di un repository (locale) indipendente, è possibile inviare questo tramite ssh ad altri repository, ad esempio uno:
- Che si trova sull'host remoto in cui il sito dovrebbe essere distribuito in (repository nudo).
- Questo ha gli hook per fare in modo che un altro repository su quell'host si fonda effettivamente nelle modifiche che hai appena spinto.
Questo è delineato in Un flusso di lavoro Git incentrato sul web (novembre 2008; di Joe Maller) .
Se si dispone quindi di uno switcher di configurazione che sceglie il calcestruzzo in wp-config.phpbase al sistema su cui è in esecuzione, è anche possibile configurare centralmente tutti gli host (sviluppo, live, staging, amici, ...) all'interno del repository.
Le modifiche a monte in WP vengono semplicemente recuperate e unite nella sottostruttura.
Plugin appena aggiornati e impegnati.
La distribuzione è semplice $ git push remote.
Esegui backup giornalieri sull'host remoto per i repository git, il database e i file caricati e questo è economico, intuitivo e flessibile. Questo funziona bene per le configurazioni a sviluppatore singolo e per i piccoli team perché tutti possono effettuare il checkout dalla riproduzione remota sul telecomando.
Ci sono alcuni avvertimenti:
Ora con la tua lista di controllo e l'installazione come indicato sopra:
1. Vorrei avere il mio ambiente git sul mio server internamente, non usando Github per gestire i repository.
Github gestisce solo repository upstream qui (Wordpress), non il tuo.
2. Creazione automatica di sottodomini al momento della creazione del ramo git (development.domain.com, ryan.development.domain.com) - Probabilmente alcuni hook della shell shell sarebbero ideali per questo.
L'installazione come indicato è un approccio modulare con un repository per sito. Può gestire tutti gli host di sviluppo che desideri, allo stesso modo potrebbe funzionare bene con un'installazione multi-sito per gestire più domini, ma questo conterebbe come una configurazione wordpress in questo approccio.
3. Phing PHP / Shell script Gestione della migrazione db (qualcosa come questo http://interconnectit.com/products/search-and-replace-for-wordpress-database/ ) per gestire la sostituzione di database serializzata dopo aver premuto
Questo non è necessario qui poiché solo il codice è sotto il controllo della versione, i database sono indipendenti tra sviluppo (, gestione temporanea) e produzione come dovrebbe essere.
Potresti essere alla ricerca di uno script di installazione che esegua correttamente la migrazione del dominio, ma anche con un codice migliore (disponibile) che si occupa della ricerca e della sostituzione di dati serializzati, in questa configurazione qui normalmente non è necessario poiché fai semplicemente passare le modifiche in diretta , per i casi di test è possibile creare rapidamente il contenuto nel database di sviluppo, che di solito è il problema più piccolo (dalla mia esperienza pratica, il tuo potrebbe essere diverso, ma suggerirei anche di mantenere tali argomenti relativi alla migrazione del database su questioni relative possedere qui sul sito - ma per favore chiedetelo).
Gestisco circa 200 siti sul mio server e vorrei iniziare a implementare questi siti in un ambiente di flusso di lavoro git forte in modo da poter semplificare il mio lavoro molto meglio.
Non riesco a immaginare come sarebbero diventati quei siti in un ambiente di flusso di lavoro con string git. Forse gli script di configurazione e i dati di configurazione che gestisci qui saranno mantenuti sotto il controllo della versione di git. Potrebbe avere senso. Altrimenti, per la mera quantità di siti, penso che non abbia alcun senso mantenere tutti quelli in un repository git. Forse nemmeno uno di quelli perché ciò che ho descritto sopra è per i siti sviluppati (incluso il codice core WP), non solo per le attività di installazione. Quindi probabilmente dovrai prima di tutto crearti una piccola mappa di quei 200 siti e come interagiscono tra loro e da quali pacchetti (core WP, Plugin, Temi) consistano quei siti. La prima cosa potrebbe essere la creazione di un foglio di calcolo / matrice e inserire tutti i siti.
È quindi possibile salvarlo come CSV, metterlo sotto controllo di versione e fare in modo che gli script di distribuzione facciano il loro lavoro in base a quel file.
E se ho imparato qualcosa con le attività di automazione: segui la filosofia Unix, usa gli strumenti esistenti e ben funzionanti (è meglio passare mezza giornata a leggere alcuni comandi e poi a cercare alternative perché per la maggior parte dei lavori, i problemi sono stati risolto già) e concentrarsi sugli strumenti da riga di comando. Sono i più potenti.