Come si esegue una versione di un'app Web mentre si sviluppa la versione successiva?

Question

Ho appena terminato un'app Django su cui desidero ottenere feedback da utenti esterni. Mi piacerebbe lanciare una versione e quindi biforcare una versione privata in modo da poter incorporare il feedback e aggiungere più funzionalità. Sto pianificando di fare molte piccole iterazioni di questo processo. Sono nuovo allo sviluppo web; come fanno tipicamente i siti web? Si tratta semplicemente di copiare la mia cartella di progetto Django in un'altra directory, avviare il server lì e continuare il mio lavoro di sviluppo nella directory originale? O preferirei utilizzare un sistema di controllo della versione? La mia intuizione è che è il secondo, ma se è così, sembra un argomento enorme con molti usi (ad esempio, collaborazione, che non si applica qui) e non so da dove iniziare.

Answer 1

1) URL separati www.yoursite.com vs test.yoursite.com. puoi anche fare www.yoursite.com e www.yoursite.com/development, ecc. Puoi anche creare un/beta o/staging ..

2) Conservare database separati, uno per la produzione e uno per lo sviluppo. Scrivi uno script che copierà il tuo database live in un database di sviluppo. Mantiene un database per ogni tipo di sito che crei. (Puoi creare una beta o un database di staging per il tuo tester). Fai il tuo lavoro nel database di sviluppo. Se si modifica la struttura del database, salvare le modifiche come file .sql che può essere caricato ed eseguito nel database del sito attivo quando si attivano tali modifiche.

3) Unisci le funzionalità nei diversi siti con il controllo della versione. Attualmente sto giocando con una installazione di subversion per le app Web con stalla (trunk), una per staging e una per lo sviluppo. I tag di sviluppo e le filiali vengono uniti in staging, quindi i tag/rami di staging vengono uniti in stable. Il controllo della versione ti consente di gestire il codice sorgente nel modo che preferisci. Dovrai trovare una metodologia che funzioni per te e usarla.

4) Considerare l'automazione della creazione. Pubblicherà il tuo sito automaticamente. Dai un'occhiata a http://ant.apache.org/. Può guidare un sacco di controllo automatico del codice e caricarlo su ogni sito specifico come potrebbe essere necessario.

5) Giocattolo del mese: Esiste un'utilità chiamata cUrl che può risultare utile. Fa molto dalla riga di comando. Questo potrebbe andar bene se lo fai nel caso in cui tu non voglia usare tutti o alcuni di Ant.

Buona fortuna!

Answer 2

In genere si utilizza il controllo della versione e si hanno due domini: il proprio sito web e test.your-site.com. Quindi your-site.com aggiornerà sempre il trunk, che è l'ultima versione di spedizione corrente. Faresti il ​​tuo sviluppo in un ramo del tronco e test.your-site.com aggiornerebbe a tale scopo. Quindi unisci periodicamente le modifiche dal ramo di sviluppo al trunk.

Answer 3

Quello che faccio è esportare una copia del mio repository SVN e mettere i file sul server di produzione live, quindi mantenere una macchina virtuale con una copia di lavoro di sviluppo e inviare le modifiche al repository quando ho finito.

Answer 4

Jas Panesar ha la migliore risposta se lo chiedi in termini di sviluppo, certamente. Cioè, se stai solo chiedendo come mantenere facilmente i tuoi nuovi sviluppi separati dal sito che è già in esecuzione. Tuttavia, se la tua domanda era in realtà chiedendo come eseguire entrambe le versioni simultaneamente, allora ecco i miei due centesimi.

L'installazione ha molto a che fare con questo, ma io consiglio sempre di eseguire web server basati sui processi in primo luogo.Cioè, non usare server thread (meno rilevanti per questa domanda) e non incorporare nel server web (cioè, non usando mod_python, che è la parte rilevante qui). Quindi, hai uno o più processi che ricevono richieste HTTP dal tuo server web (Apache, Nginx, Lighttpd, ecc.). Ora, quando vuoi provare qualcosa in diretta, senza intaccare il tuo normale sito in esecuzione, puoi far apparire un processo che serve richieste che non ricevono mai richieste regolari come ad altri. Cioè, gli utenti normali non lo vedono.

È possibile impostare un sottodominio che punti a questo ed è possibile installare il middleware che reindirizza l'utente "speciale" alla versione beta. Ciò consente di srotolare nuove funzionalità per alcuni utenti, ma non per altri.

Ora, i maggiori problemi si presentano con le modifiche al database. La migrazione dello schema è un grosso problema e qualcosa a cui la maggior parte di noi non presta mai attenzione. Penso che l'esecuzione side-by-side sia ottima, perché ti costringe a eseguire correttamente le migrazioni dello schema. Cioè, non puoi semplicemente chiudere tutto ed eseguire lunghe modifiche allo schema prima di ripristinarlo. Non vedresti mai nessun sito remotamente importante a farlo.

La chiave sono quei piccoli passi. È necessario avere sempre due versioni del codice in grado di accedere allo stesso database, quindi le modifiche apportate al nuovo codice non devono interrompere il codice precedente. Questo si risolve in alcuni passaggi che puoi sempre fare:

• È possibile aggiungere una colonna con un valore predefinito o facoltativo. Il nuovo codice può usarlo e il vecchio codice può ignorarlo.
• È possibile aggiornare la versione live con il codice che sa utilizzare una nuova colonna, a quel punto è possibile renderlo necessario.
• È possibile fare in modo che la nuova versione ignori una colonna e quando diventa la versione principale, è possibile eliminare quella colonna.

È possibile eseguire questi piccoli passaggi per migrare tra qualsiasi schema. È possibile aggiungere in modo iterativo una nuova colonna che sostituisce una vecchia, distribuire il nuovo codice e rimuovere la vecchia colonna, il tutto senza interrompere il servizio.

Detto questo, è la tua prima app web? Probabilmente puoi romperlo. Probabilmente hai pochi utenti :-) Ma è fantastico che tu stia facendo questa domanda. Molti "professionisti" sono giusti a chiederlo mai, e anche in questo caso meno rispondono.