localhost + staging + ambienti di produzione?

Question

Ho un sito Web che dice www.livesite.com che è attualmente in esecuzione. Ho sviluppato una nuova versione del sito web sul mio computer locale con http://localhost e poi ho commesso le mie modifiche con svn su www.testsite.com dove testerei il sito sul server livesite.com ma sotto un altro dominio (è lo stesso ambiente come il sito live ma con un dominio diverso).

Ora sono pronto per rilasciare la nuova versione su livesite.com. Farlo per la prima volta è semplice, potrei semplicemente copiare & incollare tutto da testsite.com a livesite.com (non è sicuro che sia il modo migliore per farlo).

Voglio mantenere testsite.com come sito di test in cui spingere gli aggiornamenti, testarli e una volta soddisfatto spostare su livesite.com ma non sono sicuro di come farlo dopo il lancio del nuovo sito .. I don Penso che copiare la copia dell'intera directory sia il modo giusto per farlo e interromperà le operazioni degli utenti attuali su livesite.com.

Voglio anche mantenere la mia storia di svn su testsite.com. Qual è il modo corretto di farlo con SVN? Grazie mille!

Answer 1

Altre risposte che citano Hudson o Weploy sono buone.Coprono più problemi di quanto segue. Detto questo, quanto segue potrebbe essere sufficiente.

Se ritieni che sia eccessivo, ecco il modo in cui il povero uomo lo fa con SVN e un piccolo sysadminning creativo.

Rendi il tuo documento proudction root un link simbolico, non una directory effettiva. Significa che hanno qualcosa di simile:

/var/www/myproject-1-0-0 
/var/www/myproject-1-1-0 
/var/www/myproject-1-1-1 
/var/www/html -> myproject-1-1-1 

Ciò significa che è possibile controllare il codice sulla produzione (ad esempio, myproject-1-1-2) senza sovrascrivere roba servito. Poi si può passare basi di codice vicino-istantaneamente facendo qualcosa di simile:

$ rm html && ln -s myproject-1-1-2 html 

avrei più consiglio di non fare un export svn checkout/svn del tronco sulla scatola di produzione. Invece, crea un ramo prima del tempo (chiamalo qualcosa come myproject-X-Y-Z). In questo modo se hai bisogno di fare un po 'stressante modifica del codice di produzione, puoi ricondurlo al ramo e unirlo al tronco una volta che l'incendio si è spento)

Lo faccio molto, e funziona abbastanza bene. Tuttavia, presenta alcuni inconvenienti principali:

Principalmente, è necessario gestire le migrazioni del database o altri script di aggiornamento, tutto da soli. Se si dispone di script (plain-old-SQL o qualcosa di più coinvolto), è necessario pensare a come meglio eseguirli. I tempi morti di una volta, forse solo un minuto, potrebbero non essere una cattiva idea. È possibile mantenere un "sito di manutenzione" in giro (/ var/www/mainenance) e puntare il collegamento simbolico lì per qualche istante, se necessario.

Questo metodo non è così bello come Weploy, ad esempio, ma per progetti relativamente piccoli (eseguiti su un singolo server, con database non enormi), è spesso abbastanza buono e semplice.

Answer 2

La mia risposta sarà complicare le cose un po ', ma qui va:

Vorrei per questo tipo di scenario utilizzare Hudson.

Hudson consentirà di avere un Distribuzione automatica/pulire la directory corrente fuori/aggiungere nuovi da svn processo. Puoi quindi preoccuparti dello sviluppo e meno di jugling e distribuzione da un posto all'altro.

L'avvertenza è che è necessario imparare un po 'su come impostare Hudson e su come fare lui lavoro per voi.

Come iniziare con PHP for Hudson

Penso che dovrebbe arrivare sulla strada giusta, un po 'di lavoro come ho detto, ma paga fuori in seguito.

Answer 3

Se cambia solo il codice del lato server, è possibile copiare semplicemente il codice e le cose andranno bene. Ma anche lì devi pensare alla possibilità di persone a metà interazione. Se il codice del lato client cambia, specialmente se si utilizza fortemente ajax, sarà necessario convincere gli utenti attuali a ricaricare le proprie pagine. Se anche il database cambia, assicurati che nessuna transazione di database avvenga durante il tempo in cui stai applicando gli script di modifica del database.

In tutti i casi, e indipendentemente dal fatto che si stia utilizzando uno strumento di integrazione continua, ritengo sia più sicuro fare il downtime per applicare queste modifiche. Uno dei motivi per cui le persone hanno l'adesivo "beta" sui loro siti è che possono disconnettere tutti e chiuderli tutti per applicare le modifiche senza preavviso. Finché non lo fanno molto spesso possono farla franca anche loro. Una volta terminato il beta, l'applicazione delle modifiche diventa una cerimonia in cui si inizia ad annunciare in anticipo settimane di inattività, quindi si ottiene una finestra da 30 minuti a qualche ora per applicare tutte le modifiche.

Per questioni di base come l'eliminazione di errori di sicurezza nel sistema operativo o del software di sistema, l'aggiunta di hardware, ecc. È possibile evitare tempi di inattività se il bilanciamento del carico è applicato e le patch vengono applicate una per una.