Hai delle strategie efficaci per il lancio di una v2 di un sito WP?


12

Il mio team e io stiamo lavorando con un cliente che ha un sito WordPress esistente con un bel po 'di contenuti e un tema personalizzato che hanno creato. È un blog di gruppo, nel senso che ha diversi blogger in tutto il mondo che aggiungono e modificano continuamente contenuti.

Il nostro compito è creare un tema completamente nuovo, con alcune nuove funzionalità. Alcune di queste funzionalità richiederanno nuovi widget personalizzati, plugin e campi del database.

Attualmente stiamo lavorando sulle nostre macchine di sviluppo e le integriamo in un singolo server di sviluppo. Tutto il codice è aggiornato in SVN. Il nostro DBA nominato sta unendo manualmente tutte le modifiche al database nel DB di sviluppo in questo momento, anche se spero che sarà in grado di automatizzarlo presto.

Abbiamo appena iniziato a parlare del nostro processo di rilascio della produzione. Significato: una volta terminato, come possiamo trasferire tutto il nostro codice personalizzato sul server di produzione (dal vivo) senza problemi e con il minor disturbo possibile?

Abbiamo in mente alcuni piani, ma mi piacerebbe sapere come anche altri hanno affrontato questo problema. Ci sono delle migliori pratiche da seguire o insidie ​​note da evitare?

Risposte:


4

Se segui i consigli di SethMerrick, puoi ridurre notevolmente il tempo di commutazione abbassando il TTL sui record DNS appropriati a 5 minuti o più ore (a seconda di quale sia il TTL corrente) prima di modificare l'indirizzo IP.

In questo modo stai dicendo ai server DNS remoti di memorizzare nella cache l'indirizzo solo per 5 minuti. Una volta modificato l'IP, è possibile aumentare il TTL a qualunque cosa fosse prima. Per ridurre ulteriormente l'effetto, eseguire la commutazione durante un periodo di traffico ridotto.


Abbiamo appena iniziato a farlo, per coincidenza. Aiuta sicuramente. Non possiamo permetterci un lungo periodo di spiegamento. Grazie per aver aggiunto quel suggerimento!
Mike Lee,

Si noti che è necessario modificare il TTL molto tempo prima di modificare effettivamente l'IP . In altre parole, se il TTL è di una settimana, è necessario modificare il TTL in 5 minuti una settimana prima di modificare l'IP, in modo che tutti saranno sul nuovo TTL quando lo fanno.
Daniel C. Sobral,

2

Non sono sicuro che ciò sia applicabile, ma ho appena attraversato un processo simile di migrazione e aggiornamento simultanei di un sito a traffico elevato.

La strategia di base era quella di lavorare su un server di gestione temporanea, quindi quando tutto era pronto, eseguire un dump mysql sul server live, importarlo sul server di gestione temporanea, eseguire tutte le operazioni di pulizia necessarie, quindi puntare i record DNS sul server di gestione temporanea, causando il server di gestione temporanea per diventare il nuovo server live.

Il punto difficile è quindi unire tutti i dati che si accumulano durante la propagazione DNS nel server di gestione temporanea (che ora è il server live). In altre parole, se trascorrono 30 ore tra quando esegui il dump / aggiornamento di MySQL e quando la propagazione del DNS è completa, dovrai unire selettivamente 30 ore di record dal vecchio sito a quello nuovo.

Non è un processo continuo, ma quando abbiamo trascorso una settimana lungo la strada tutti i nodi si sono appianati.


In questo scenario, renderebbe il vecchio sito effettivamente di sola lettura mentre il DNS è in transizione per impedire modifiche al sito che non verranno migrate?
Trevor Bramble,

Questo è un approccio alternativo, per impedire che qualsiasi nuovo dato venga aggiunto al db del vecchio sito durante la transizione. L'approccio che ho menzionato sopra, tuttavia, rende attivo il vecchio sito durante la transizione, quindi unisce manualmente tutte le voci di db aggiuntive visualizzate durante la transizione (nuovi post, commenti, ecc.) Nel nuovo sito. modifica: volevo solo ricordare che il suggerimento di acterry su TTL Records è un consiglio fantastico.
SethMerrick,

Abbiamo fatto qualcosa di simile a questo. Non senza soluzione di continuità, ma ehi, funziona.
Mike Lee,

2

@Mike Lee: Ottima domanda, e uno dei santi graal di WordPress (o di uno qualsiasi dei CMS open source tradizionali con cui ho familiarità in materia come Drupal, Joomla, et.)

Anche se certamente non è destinato a risolvere il tuo caso d'uso, controlla la mia risposta a una domanda correlata che descrive un plug-in di livello beta che ho appena reso disponibile tramite WordPress Answers Exchange chiamato WP Migrate Webhosts (sì, faccio schifo quando si tratta di denominazione creativa .)

Ma voglio anche risolvere il caso d'uso che descrivi con un plugin e attualmente sto pensando a come farlo. Sto pensando che il modo di approcciarlo sia rinunciare a risolverlo genericamente e invece affrontare i modelli noti che esistono in WordPress e quindi consentire a chiunque altro di " agganciare " il mio plugin per casi d'uso speciali. Sto anche pensando che un approccio sia serializzare i dati e le strutture in WordPress come dati in un file PHP in modo che un futuro plug-in possa applicare tali modifiche come delta, proprio come un sistema di controllo del codice sorgente applica delta per arrivare alla versione corrente di sorgente codice.

Quindi, mentre non sto rispondendo o risolvendo completamente il tuo problema, spero di darti un buon spunto di riflessione e spero anche che tu o qualcun altro vogliate collaborare a un'eventuale soluzione.


WP Migrate Webhosts sembra un plug-in necessario. Grazie per averlo condiviso e questo feedback!
Mike Lee,

Penso di sì. Spero di ottenere una collaborazione in modo che io e altri possiamo evolverla per essere super utile! Grazie per il voto positivo.
MikeSchinkel,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.