sfondo

Mi sto avvicinando alle fasi finali della costruzione del mio primo sito WordPress abbastanza grande, e ora sto incontrando un po 'di attrito. Per la maggior parte, il sito è stato sviluppato sul mio computer locale e invierei le modifiche a un server di gestione temporanea per la revisione ( vedi questa domanda per ulteriori informazioni ). La soluzione con cui ho finito ha funzionato abbastanza bene quando stavo solo modificando il contenuto, ma ora alcune altre persone stanno modificando il contenuto mentre ho ancora delle funzionalità da aggiungere. L'idea era: potremmo fare le cose più rapidamente se le funzionalità e il contenuto si unissero in concerto ... ma ora non ne sono così sicuro.

Al momento, sul server di gestione temporanea sono presenti contenuti diversi nel database rispetto al mio computer locale. Va bene da solo, poiché non ho bisogno della copia del corpo finale sul mio computer locale, ma ho bisogno di fare più sviluppo che influenzerà il database (installa / scrivi un paio di plugin in più che hanno bisogno delle loro tabelle).

La mia domanda è:

C'è un modo semplice per automatizzare l'unione dei database in modo che più persone possano lavorare su un'installazione di WordPress? Ovviamente, potrei semplicemente esportare le tabelle che so sono cambiate sul mio computer locale e inviarle al server di gestione temporanea, ma è possibile che sul server di gestione temporanea ci siano anche cose che vorrei far cadere. Potrei prendere l'output SQL di entrambi i DB e diffonderli ... ma questo sembra noioso e hacker. Mi chiedo se questo è un problema che altri hanno risolto; se esiste un modo accettato dalla comunità per gestire questo genere di cose.

Grazie!

Ho fatto questa domanda più di un anno fa e durante quel periodo abbiamo aggiunto più persone al nostro team e sviluppato un numero molto più grande di siti in WordPress. Volevo seguire il nostro processo nel caso potesse aiutare qualcun altro.

Tutto in Git

Questo era qualcosa che stavo facendo anche quando ho posto la domanda, ma è bene richiamare questo punto. L'uso di Git non solo ci ha aiutato a essere più produttivi, ma ci ha anche salvato diverse volte i nostri culi collettivi.

Hai mai avuto bisogno di effettuare importanti ristrutturazioni strutturali in un sito, ottenere l'approvazione per tali ristrutturazioni da un cliente e nel frattempo apportare piccoli aggiornamenti alla versione non rinnovata? Abbiamo, e Git ci ha permesso di farlo. Descrivere questa configurazione sarebbe un po 'complicato, ma le basi sono che abbiamo creato un nuovo ramo, trasferito quel ramo sul server e collegato un sottodominio a quel ramo.

Siamo stati salvati anche da Git. Ovviamente ci consente di ripristinare le modifiche, il che è fantastico, ma ci consente anche di ripristinare le vecchie versioni dei file. Ciò significa che se un cliente chiede "Ricorda come ha funzionato questa parte del sito circa un anno fa? Possiamo riportarlo indietro?", La risposta è sì, anche se la persona a cui era stato chiesto non faceva parte di quel progetto un anno fa.

Oltre a questi punti, significa anche che non siamo mai bloccati senza i file di cui abbiamo bisogno. Possiamo sempre estrarre la versione più recente del sito da qualsiasi macchina e iniziare a apportare modifiche.

Usa Git per distribuire

Facciamo il nostro hosting WordPress su Media Temple e ci piacciono molto. Non sono il fornitore più economico, ma il loro servizio è eccellente e i loro server sono davvero ben configurati. Forniscono anche Git per impostazione predefinita. Ciò significa che possiamo configurare il server come repository Git e applicare le modifiche in questo modo invece di utilizzare SFTP. Significa anche che fare un lavoro sul server non corre il rischio di essere sovrascritto (dato che tali modifiche possono essere unite e rimandate).

Poiché utilizziamo BitBucket come host Git, qui è richiesto un po 'di lavoro extra. Prima di tutto usiamo i file .ssh / config in modo da poter digitare cose come ssh sitenameaccedere ai nostri server (usiamo anche SSH senza password , il che rende questo super facile). Ci assicuriamo inoltre di utilizzare sempre le passphrase ssh (Mac OS X rende tutto molto semplice consentendo di memorizzare la passphrase in Keychain.app ). Infine, aggiungiamo la riga ForwardAgent alla voce .ssh / config sugli host da cui vogliamo estrarre. Ciò significa che abbiamo bisogno solo della chiave pubblica SSH di ogni persona in BitBucket e non della chiave pubblica di ciascun server. Ci assicuriamo inoltre di mantenere la .gitdirectory una directory sopra la directory HTML pubblica.

Dump di database automatizzati

Una volta che il server è in modalità di produzione, ci assicuriamo di eseguire automaticamente il backup del nostro database, per ogni evenienza .

Ognuno ha il proprio wp-config

Poiché tutti abbiamo i nostri nomi utente e password del nostro database locale e poiché potremmo usare nomi e meccanismi di servizio diversi, ognuno di noi mantiene il proprio file wp-config. Ognuno di questi è memorizzato in Git con un nome simile wp-config-gavin.phpe quando vogliamo usare quella configurazione, lo colleghiamo a symlinkwp-config.php (che viene ignorato da Git usando .gitignore ).

Questo ci consente anche di sovrascrivere l' siteurlopzione nella wp_optionstabella del database in questo modo:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Ciò impedisce a WordPress di esaminare il database per la posizione del server e significa che non ci sono strane differenze nella posizione tra installazioni locali e server.

Un'ultima nota sui file wp-config.php: assicurati di memorizzarli sopra la directory HTML pubblica e fai leggere le autorizzazioni solo per l'utente web . Questo fa una grande differenza nel proteggere WordPress.

Il problema del database

Infine, la carne della questione.

Quello che ho dovuto accettare è che, quando si utilizza WordPress, non esiste un buon modo per "unire" le modifiche al database. Invece, abbiamo dovuto sviluppare regole di condotta per risolvere questo problema. Le regole sono abbastanza semplici e finora ci hanno servito bene.

Durante lo sviluppo, c'è una sola persona che "possiede" il sito. Quella persona di solito esegue l'installazione (mettendo insieme il pacchetto di hosting, avviando il progetto Basecamp, tagliando il design, quel genere di cose). Una volta che quella persona è a un punto ragionevole, scarica il database per l'installazione di WordPress e inseriscilo in Git. Da quel momento in poi, tutti coloro che eseguono lo sviluppo utilizzano tale dump del database e il proprietario è l'unico che apporta modifiche al database.

Una volta che la creazione del sito è un po 'più avanti, il sito viene inserito in un server. Da quel momento in poi, il database del server è canonico. Tutti (incluso il proprietario) devono apportare tutte le modifiche al database sul server e rimuoverle per lo sviluppo e i test locali.

Questo processo non è perfetto. È ancora possibile che qualcuno possa aver bisogno di apportare modifiche nel backend di WordPress localmente durante lo sviluppo, e quindi di dover apportare di nuovo tali modifiche in produzione. Tuttavia, abbiamo scoperto che questo genere di cose è raro e questo processo funziona abbastanza bene per noi.

Lavoro su tale installazione e ho già risposto a domande come questa . Di seguito è la mia configurazione preferita per questo tipo di lavoro. Perché vuoi unire i database invece di sostituire un database esistente, aggiungerei a questi un avvertimento a non usare il flag --add-drop-table quando esegui il dump MySQL.

• Passaggio 1. Mysqldump il database di sviluppo
• Passaggio 2. Sostituire tutte le istanze di development.domain.com in production.domain.com ^^
• Passaggio 3. Accedere a MySQL, eseguire un comando SOURCE per importare dati, ad es source /path/to/file

^^ Come sostituire tutte le istanze del vecchio dominio con nuove: (1) Copia lo script qui sotto. (2) chmod +x. (3) Eseguilo.

Uso: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Sto sperimentando diverse soluzioni a questo stesso problema in questo momento. È sicuramente difficile.

La mia attuale soluzione è fare un dump mysql locale usando il flag --skip-extended-insert. Credo che questo flag causi la generazione di un'istruzione record di inserimento per ogni riga del database, rendendo il dump un po 'più semplice da unire. Ho preso quel trucco da questo articolo: http://www.viget.com/extend/backup-your-database-in-git/ .

Quindi controllo il file risultante .sql datadump usando Git insieme ai file sorgente del sito. Quando un altro sviluppatore esegue il pull down delle modifiche al codice, il file .sql arriva con esso. Quindi importa questo file nella sua versione locale del database. Entrambi abbiamo impostato i nostri rispettivi database locali allo stesso modo su entrambe le macchine, utilizzando MAMP, quindi non è necessario effettuare alcuna ricerca e sostituzioni.

Ci sono stati problemi di unione, quindi stiamo provando ad adottare un approccio "a turno" per tutto ciò che causerà una modifica del database. Prima di fare qualsiasi cosa in Wordpress che cambierà il database, mi assicuro che abbia controllato il suo ultimo dump, lo abbia estratto e importato, e poi gli ho chiesto di non apportare modifiche al DB fino a quando non avrò effettuato e verificato il mio. Questo ovviamente non è l'ideale e sto cercando una soluzione migliore ma è un inizio. Ci dà anche il controllo della versione del DB, il che è carino.

Potrei finire per impostare un database di sviluppo condiviso sul server e provare a connettere entrambe le nostre copie locali del sito Web allo stesso DB tramite tunneling SSH. Questo approccio, tuttavia, incontrerà problemi ogni volta che uno di noi installa un plugin. Fondamentalmente i file PHP e MySQL DB non saranno sincronizzati.

Sono ansioso di sapere come gli altri stanno affrontando questo problema.