Esiste un sovraccarico associato all'integrazione continua, ad es. Impostazione, riqualificazione, attività di sensibilizzazione, interruzione per correggere "bug" che si rivelano essere problemi di dati, separazione forzata degli stili di programmazione delle preoccupazioni, ecc.
A che punto l'integrazione continua si ripaga da sola?
EDIT: questi erano i miei risultati
L'allestimento è stato CruiseControl.Net con Nant, lettura da VSS o TFS.
Ecco alcuni motivi di errore, che non hanno nulla a che fare con l'installazione:
Costo dell'indagine : il tempo impiegato per verificare se una luce rossa è dovuta a un'incongruenza logica reale nel codice, nella qualità dei dati o in un'altra fonte come un problema di infrastruttura (ad esempio un problema di rete, una lettura del timeout dal controllo della fonte, server di terze parti è inattivo, ecc. ecc.)
Costi politici sull'infrastruttura : ho considerato di eseguire un controllo "infrastruttura" per ciascun metodo nell'esecuzione del test. Non avevo soluzione al timeout se non per sostituire il server di build. La burocrazia si è messa in mezzo e non è stato possibile sostituire il server.
Costo del fissaggio dei test unitari : una luce rossa a causa di un problema di qualità dei dati potrebbe essere un indicatore di un test unitario scritto male. Pertanto, i test unitari dipendenti dai dati sono stati riscritti per ridurre la probabilità di una luce rossa a causa di dati errati. In molti casi, i dati necessari sono stati inseriti nell'ambiente di test per poter eseguire accuratamente i test unitari. Ha senso affermare che rendendo i dati più affidabili, il test diventa più robusto se dipende da questi dati. Certo, ha funzionato bene!
Costo della copertura, ovvero scrivere test unitari per codice già esistente : si è verificato il problema della copertura unit test. C'erano migliaia di metodi che non avevano test unitari. Quindi, sarebbe necessaria una considerevole quantità di giornate uomo per crearle. Dato che sarebbe stato troppo difficile fornire un caso aziendale, è stato deciso che i test unitari sarebbero stati utilizzati per qualsiasi nuovo metodo pubblico in futuro. Quelli che non avevano un test unitario erano definiti "potenzialmente a infrarossi". Un punto interessante qui è che i metodi statici erano un punto controverso nel modo in cui sarebbe stato possibile determinare in modo univoco come un metodo statico specifico aveva fallito.
Costo delle versioni su misura : gli script Nant vanno solo fino ad ora. Non sono così utili per, diciamo, build CMS dipendenti per EPiServer, CMS o qualsiasi distribuzione di database orientata all'interfaccia utente.
Questi sono i tipi di problemi che si sono verificati sul server di build per esecuzioni orarie di test e build di QA durante la notte. Sono lieto che questi non siano necessari in quanto un build build può eseguire queste attività manualmente al momento del rilascio, in particolare, con una banda di un uomo e una build piccola. Quindi, le build a singolo passaggio non hanno giustificato l'uso della CI nella mia esperienza. Che dire delle build più complesse a più fasi? Questi possono essere dolorosi da costruire, soprattutto senza una sceneggiatura di Nant. Quindi, anche dopo averne creato uno, questi non hanno avuto più successo. I costi per risolvere i problemi di luce rossa hanno superato i benefici. Alla fine, gli sviluppatori hanno perso interesse e hanno messo in dubbio la validità della luce rossa.
Dopo averlo provato, credo che la CI sia costosa e che ci sia molto da lavorare sui bordi invece di portare a termine il lavoro. È più conveniente impiegare sviluppatori esperti che non creano problemi con grandi progetti piuttosto che introdurre e mantenere un sistema di allarme.
Questo è il caso anche se quegli sviluppatori se ne vanno. Non importa se un buon sviluppatore se ne va perché i processi che segue assicurano che scriva le specifiche dei requisiti, le specifiche di progettazione, si attiene alle linee guida di codifica e commenta il suo codice in modo che sia leggibile. Tutto questo è stato rivisto. Se ciò non accade, il suo caposquadra non sta facendo il suo lavoro, che dovrebbe essere raccolto dal suo manager e così via.
Perché CI funzioni, non è sufficiente scrivere unit test, tentare di mantenere la copertura completa e garantire un'infrastruttura funzionante per sistemi di dimensioni considerevoli.
La linea di fondo: ci si potrebbe chiedere se la correzione di tanti bug prima del rilascio sia desiderabile anche da una prospettiva aziendale. CI richiede molto lavoro per acquisire una manciata di bug che il cliente potrebbe identificare in UAT o che la società potrebbe essere pagata per la riparazione come parte di un contratto di servizio alla scadenza del periodo di garanzia.