Quali modelli di software sono appropriati per le build giornaliere e l'integrazione continua?

I tuoi amici sono pigri e IMO poco professionale - il mondo li passerà presto.

Daily builds were meant for projects following Agile practices. It does not work for the waterfall model.

Non ho un riferimento definitivo a portata di mano, ma le build giornaliere erano comuni almeno fino agli anni 90, quindi erano pre-date Agile e la timeline * Unified Process. Ogni volta che hai più di un paio di sviluppatori, QUALCUNO controllerà qualcosa che può essere testato, e allo stesso tempo può ora automatizzare i controlli per rompere la compilazione.

automated testing is impractical for projects where the graphics part ...

I test automatici sono uno strumento per risparmiare tempo e denaro. Perché qualcuno dovrebbe voler rendere il software più costoso del necessario?

not necessary to have configuration management

È semplicemente pazzesco. Tutti gli sviluppatori usano versioni diverse di librerie di terze parti? Nessuno tiene traccia delle funzionalità da distribuire in ogni versione? Nessuna capacità di diramazione nel sistema di controllo versione?

Per essere onesti nei confronti dei tuoi partner di discussione, se ciò che hanno funziona, allora, bene, funziona. Probabilmente continuerei a venderli in qualche modo, ma posso capire la resistenza.

C'è un sovraccarico nell'ottenere la configurazione CI in primo luogo e un sovraccarico per gestirlo. Non è un gran problema, ma io punto in bianco rifiuto di essere "The CI guy" perché so che a un certo punto diventerà un compito indesiderato.

Tuttavia, una volta che ho nominato qualcun altro per farlo configurare, per lo meno è utile sapere che il codice archiviato è in fase di compilazione. Questo solo beneficio è significativo.

Il lato di prova di questo è un po 'irrilevante qui. La build dell'elemento della configurazione deve eseguire i test, ma questi test non dovrebbero esistere se non servono a scopi utili. Ci sono sempre casi di test che hanno senso comunque. Questo è anche un punto di resistenza per molti sviluppatori.

Alcune persone vedono ancora la copertura del test del codice come una statistica d'oro della salute del progetto. Non lo è. Preferirei avere una copertura 1pc con l'1pc appropriato, test di qualità, piuttosto che la copertura 80pc di "Test che ho scritto perché avevamo bisogno di arrivare alla copertura 80pc".

E questo è l'ultimo problema. Una volta che hai CI, qualcuno ti chiederà le statistiche di copertura, poi ti chiederanno perché la tua copertura non è più alta, quindi qualcuno ti invierà un link a un grande pacchetto di test dell'interfaccia utente che automatizza ... Nella loro mente sono passati da un processo che funziona in modo dimostrabile, a un processo che richiede più impegno per ottenere lo stesso risultato finale, lo stesso codice di lavoro che stavano distribuendo in precedenza.

Daily builds were meant for projects following Agile practices. It does not work for the waterfall model.

Direi: cascata pura non funziona per più di progetti banali con una vita così piccola che la creazione di una build giornaliera sarebbe troppo grande. Ma se la durata del progetto è di almeno alcuni mesi, e intendi "cascata con cicli ricorrenti", ovviamente le build giornaliere possono avere molto senso. E anche in una cascata classica, in cui si ha un'analisi, una fase di progettazione e una fase di sviluppo, nella fase di sviluppo è necessario eseguire molte build e integrazione del codice, quindi perché non automatizzarlo e assicurarsi che le modifiche al codice vengano integrate quotidianamente?

Continuous integration required automated testing

Sciocchezze, l'IC può integrare test automatici, ma non è un requisito. Puoi comunque eseguire il test manualmente e utilizzare solo CI per assicurarti di avere una build giornaliera pronta per i tuoi tester.

One of them believes that it's not necessary to have configuration management.

Se hai un progetto in cui il ciclo di vita del tuo prodotto termina dopo la versione 1.0, allora è vero. In tutti gli altri casi, dovresti avere qualche tipo di gestione della configurazione. Ma questo è indipendentemente da CI. Inoltre, CI ti incoraggia a mantenere le tue modifiche al tuo codice base ridotte e reintegrate quotidianamente, il che è esattamente il tuo argomento contrario.

Even if they created scripts for the entire build and burn-to-cd process, creating automated tests were a problem

Vedi il mio commento, l'IC non richiede test automatici.

E ai tuoi altri punti:

you can't always know what tests you'd have to run

tutti quanti, cos'altro?

scripting a test case for it takes up too much time

Dovresti creare uno script per quei casi di test in cui applicarli manualmente più e più volte richiede troppo tempo, in modo da renderli automatici salvare la tua ora.

automated testing tools may not always support the specific kind of tests you might want to make

Perché ci sono alcuni test che hai problemi da automatizzare, non automatizzi nulla? Non sembra molto convincente per me. E chi ti ha detto che i test automatici richiedono strumenti speciali? Vorrei solo iniziare senza strumenti o solo con qualche framework xUnit lighweight.

RE: test difficili da specificare e amp; sistemi difficili da testare come i sistemi grafici.

Nella mia esperienza, test non è solo (anche?) sul test dell'output del sistema che stai creando. Si tratta di verificare che le supposizioni che hai fatto siano corrette e di continuare a verificare tali ipotesi mentre il progetto si evolve e le situazioni cambiano.

A tal fine, il posizionamento di un numero moderato di dichiarazioni di asserzione in vari punti del codice ha enormi vantaggi se combinato con un regime di integrazione continua.

Il sistema non ha nemmeno bisogno di essere esercitato con una suite completa di test unitari (sebbene questi siano una cosa buona se ne hai il tempo), anche una piccola serie di vigorosi esercizi a livello di sistema fornirà un'enorme utilità nello scoprire bug e creare fiducia.