Le build quotidiane sono la strada da percorrere per un'app Web?

Question

Joel sembra pensa molto alle build quotidiane . Per un'applicazione compilata tradizionale posso certamente vedere la sua giustificazione, ma come fa questo parallelo allo sviluppo web - o no?

Un po 'del progetto che sto chiedendo - Ci sono 2 sviluppatori che lavorano su un'app Web Django (Python). Abbiamo 1 repository svn. Ogni sviluppatore mantiene un checkout e la propria copia di MySQL in esecuzione localmente (se non si ha familiarità con Django, viene fornito in bundle con il proprio server di test, in modo molto simile alle app ASP che possono essere eseguite all'interno di Visual Studio). Sviluppo e test vengono eseguiti localmente, quindi ripristinati nel repository. La copia di lavoro effettiva del sito Web è un checkout SVN (so dell'esportazione SVN e richiede troppo tempo). Il più vicino a un 'build' è un file batch che esegue un aggiornamento SVN sulla copia di lavoro, esegue i bit di django ('manage.py syncdb'), aggiorna la cache del motore di ricerca (solr), quindi riavvia apache.

Suppongo che ciò che non vedo sia il parallelo alle app Web.

Stai realizzando un'app Web controllata dal codice sorgente con "build notturne" - in tal caso, che aspetto ha?

Answer 1

Puoi facilmente eseguire tutti i tuoi test di unità Django attraverso il framework di test Django come build notturno.

Questo è quello che facciamo.

Abbiamo anche alcuni test unitari ordinari che non sfruttano le funzionalità di Django e li eseguiamo anche.

Anche se Python (e Django) non richiedono il tipo di compilazione / link / unit test notturni che fanno i linguaggi compilati, trarrai comunque beneficio dalla disciplina quotidiana di "Don't Break The Build". E un ciclo giornaliero di test unitari di tutto ciò che possiedi è una buona cosa.

Siamo nel bel mezzo di guardare Python 2.6 (che funziona perfettamente per noi) e di eseguire i nostri test unitari con l'opzione -3 per vedere quali funzionalità deprecate stiamo usando. Avere una suite completa di unit test ci assicura che una modifica per la compatibilità di Python 3 non romperà la build. E eseguirli di notte significa che dobbiamo essere sicuri che stiamo refactoring correttamente.

Answer 2

L'integrazione continua è utile se hai i giusti processi attorno ad essa. TeamCity di JetBrains è un ottimo punto di partenza per creare familiarità:

http://www.jetbrains.com/teamcity/index.html

C'è un ottimo articolo che si riferisce direttamente a Django qui:

http://www.ajaxline.com/continuous-integration-in -django progetto

Spero che questo ti inizi.

Answer 3

Le applicazioni Web costruite in linguaggi dinamici potrebbero non richiedere una "compilazione" passo, ma può esserci ancora un numero di " build " passaggi necessari per far funzionare l'app. Gli script di build potrebbero installare o aggiornare dipendenze, eseguire migrazioni di database e quindi eseguire la suite di test per assicurarsi che il codice sia "pulito". w.r.t. l'attuale versione archiviata nel repository. In alternativa, è possibile distribuire una copia del codice su un server di prova, quindi eseguire una serie di test di integrazione Selenium con la nuova versione per assicurarsi che la funzionalità del sito principale funzioni ancora.

Potrebbe essere utile fare qualche lettura sul tema dell'integrazione continua, che è una pratica molto utile per i team di sviluppatori di webapp. Più il tuo processo di sviluppo è veloce e agile, più hai bisogno di input regolari da test automatici e metriche di qualità per assicurarti di fallire velocemente e rumorosamente su qualsiasi versione non funzionante del codice.

Answer 4

Se sei davvero solo tu e un altro sviluppatore a lavorarci, probabilmente le build notturne non ti daranno molto.

Direi che l'equivalente dell'app Web delle build notturne sarebbe un sito di staging (che può essere costruito ogni notte).

Dove le costruzioni notturne in un'area di gestione temporanea iniziano a pagare dividendi reali è quando hai clienti, project manager e addetti al controllo qualità che devono essere in grado di vedere una versione aggiornata, ma relativamente stabile dell'app. I tuoi sandbox per sviluppatori (se almeno sei come me) probabilmente passano molto tempo in uno stato inutilizzabile mentre stai rompendo le cose cercando di implementare la prossima funzione. Quindi il problema tipico è che una persona addetta al controllo qualità vuole verificare che un bug sia stato corretto, oppure un PM vuole verificare che alcune funzionalità pianificate siano state implementate correttamente, oppure un cliente vuole vedere che hai fatto progressi sul problema che gli interessa di. Se hanno accesso solo ai sandbox degli sviluppatori, c'è una buona probabilità che quando riescono a guardarlo, o la versione sandbox non è in esecuzione (dal momento che significa ./manage.py RunServer è in un terminale da qualche parte) o è in uno stato rotto a causa di qualcos'altro. Questo rallenta davvero l'intera squadra e fa perdere molto tempo.

Sembra che tu non abbia una configurazione di gestione temporanea poiché aggiorni automaticamente la versione di produzione. Ciò potrebbe andare bene se sei in modo più attento e disciplinato di me (e penso che la maggior parte degli sviluppatori) sia e non commetta mai nulla che non sia totalmente a prova di proiettile. Personalmente, preferirei assicurarmi che il mio lavoro abbia superato almeno un breve QA da parte di qualcuno diverso da me prima che raggiunga la produzione.

Quindi, in conclusione, l'installazione in cui lavoro:

• ogni sviluppatore esegue il proprio sandbox localmente (come lo fai tu)
• c'è un " comune " sandbox di gestione temporanea su un server di sviluppo che viene aggiornato di notte da un cronjob. PM, clienti e QA ci vanno. Non hanno mai accesso diretto ai sandbox degli sviluppatori.
• Esiste una distribuzione automatizzata (sebbene avviata manualmente) nella produzione. Uno sviluppatore o il PM possono " spingere " alla produzione quando riteniamo che le cose siano state sufficientemente QA e che siano stabili e sicure.

Direi che l'unico lato negativo (oltre a un po 'di sovraccarico extra che configura le build di gestione temporanea notturna) è che rende un giorno di inversione di tendenza sulla verifica dei bug. vale a dire, il QA segnala un bug nel software (basato sull'esame della build notturna di quel giorno), lo sviluppatore corregge bug e commette, quindi il QA deve attendere fino alla build del giorno successivo per verificare che il bug sia effettivamente corretto. Di solito non è un grosso problema poiché tutti hanno abbastanza cose da fare che non influiscono sul programma. Tuttavia, quando si avvicina una pietra miliare e ci troviamo in una modalità bloccata dalle funzionalità, solo bugfix, faremo aggiornamenti manuali più frequenti del sito di staging.

Answer 5

Ho avuto un grande successo usando Hudson per una continua integrazione. Dettagli sull'uso di Hudson con Python di Redsolo .

Qualche mese fa, diversi articoli che espongono implementazione continua ha suscitato molto scalpore online. IMVU ha dettagli su come distribuire fino a 5 volte a giorno .

Answer 6

L'idea alla base di build frequenti (notturne o più frequenti come in integrazione continua) è quella di ottenere un feedback immediato al fine di ridurre il tempo trascorso tra l'introduzione di un problema e il suo rilevamento. Pertanto, la costruzione frequente è utile solo se si è in grado di generare feedback tramite compilazione, test (idealmente automatizzati), controlli di qualità, ecc. Senza feedback, non ha senso.