Sviluppo, test e rilascio

Come sviluppate, testate e distribuite per vivere i vostri siti Wordpress?

Trovo sempre un po 'complicato, soprattutto per quanto riguarda i database, principalmente a causa del fatto che avere un sito di test ha bisogno di distribuire un database completamente nuovo che a volte può essere ESATTAMENTE lo stesso, tranne per il fatto che tutti i collegamenti sono cambiati URL del sito di test, anziché del sito live.

Allo stesso modo, tutti i caricamenti caricati dagli utenti dall'ultima volta in cui è stato necessario correggere un bug o sviluppare qualcosa di nuovo dovranno essere copiati sul sito di test.

Come lo fanno gli altri? Hai appena sopportato il faff? Usi sistemi di controllo versione intelligenti che aiutano?

Grazie

testing

— Thomas Clayson
fonte

Se si crea un sistema che ruota attorno alla modifica del file hosts , non è necessario eseguire il muck con il proprio DB di prova. ( wordpress.stackexchange.com/a/10943/9142 )

— Alexander Bird

C'è un po 'di filosofia personale che si inserisce in un flusso di lavoro di distribuzione. Non è una domanda facile rispondere senza conoscere la tua esperienza con i server e il controllo della versione, il tuo sistema operativo, l'hosting, l'esperienza del cliente e la cultura tecnologica, ecc ...

Ecco una domanda simile che ha molte spiegazioni.
Per la distribuzione dei contenuti, puoi consultare il plug-in RAMP di Crowd Favorite .
WP Hackers è un ottimo thread per trovare buone informazioni sulle distribuzioni.

Personalmente, mi assicuro di non codificare mai gli URL assoluti nei miei temi. Usa bloginfo () o codice URL relativi. Uso molti condizionali nel mio file wp-config.php. Ecco una versione vaniglia delle mie modifiche di wp-config.

switch($_SERVER['SERVER_NAME']){
    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
        break;
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        break;
    default: //Live
        $db_host = '';
        $db_pass = '';
}
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

Lavoro su molti siti che seguono il

local (hacking personale :) sul mio server web laptop)>
dev (test sul server client)>
stage (fonte stabile per QA - editing dei contenuti)>
produzione (sito live)

Infine, suggerirei di utilizzare uno strumento di controllo delle versioni per facilitare le implementazioni come GIT o SVN. Facilita significativamente il processo e mantiene l'integrità della fonte tra gli ambienti. L'impegno per il tuo locale è facilmente aggiornabile tramite riga di comando sul palco e produzione. È meglio durante la scoperta definire quale versione controlla che tu e il client utilizzerete fin dall'inizio se gli sviluppatori lavorano sul progetto. Personalmente uso GIT per il controllo della mia versione. Tuttavia, se un client utilizza SVN, faccio un mix dei due sul mio locale, quindi mantengo un repository per me stesso impegnandomi anche nel loro repository.

Raramente abbiamo problemi di migrazione da un ambiente all'altro. Effettuiamo una ricerca / sostituzione nel DB per modificare l'URL di conseguenza per i media incorporati, ecc ...

— Brian Fegter
fonte

Questo è molto utile! :) Grazie mille. Quindi ogni volta che si distribuisce su ciascuno dei diversi server, si duplica il database dal sito live? Dici che esegui la distribuzione su un server di gestione temporanea (stage.domain.com) per il controllo qualità e la modifica dei contenuti. Cosa succede se il database cambia mentre si esegue lo stage server sul sito live? cioè tu o il tuo cliente accedete al palco e aggiornate alcuni contenuti, ma allo stesso tempo un collaboratore pubblica un nuovo articolo sul sito live? Effettuate NUOVAMENTE le modifiche al contenuto sul sito live? Come affrontate le modifiche alla struttura del database?

— Thomas Clayson,

Mi dispiace per tutte le domande! : p Ti sono molto grato per il tuo tempo e il tuo aiuto.

— Thomas Clayson,

Su un nuovo set di funzionalità, puoi estrarre dal prod> stage. Aggiungi il contenuto per la nuova funzionalità, quindi torna indietro> prod. Da lì, stage è una copia ad alta fedeltà di prod e puoi estrarre stage> dev. Non capita spesso di ritirare il DB dallo stage. La maggior parte degli scambi con il DB avviene da uno stadio all'altro, a meno che una funzione non modifichi l'architettura db.

— Brian Fegter,

Se vuoi usare stage per la distribuzione dei contenuti e non toccare mai prod, puoi dare un'occhiata al plugin RAMP che ho pubblicato in precedenza.

— Brian Fegter,

Fai +1 su tutto quanto sopra, a condizione che alcuni plugin fastidiosi insistano nel memorizzare gli URL in array serializzati, che possono rovinare lo spostamento di cose da un DB di env a un altro. Il problema è che le matrici serializzate memorizzano le lunghezze delle stringhe e vengono modificate quando la lunghezza cambia. Pertanto, consiglierei di mantenere uguali i nomi di dominio di env se possibile, ad esempio dev.example.com, tst.example.com, www.example.com ecc.

— webaware