Esiste un sovraccarico associato all'integrazione continua, ad esempio, set up, riqualificazione, attività di sensibilizzazione, interruzione per correggere "bug" che si rivelano problemi di dati, separazione forzata di stili di programmazione di preoccupazioni, ecc.
A che punto l'integrazione continua si ripaga da sola?
EDIT: questi sono stati i miei risultati
Il set-up era CruiseControl.Net con Nant, in lettura da VSS o TFS.
Ecco alcuni motivi di errore, che non hanno nulla a che fare con la configurazione:
Costo dell'investigazione : il tempo impiegato per verificare se una luce rossa è dovuta a una vera incongruenza logica 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 del codice sorgente, il server di terze parti è inattivo, ecc. ecc.)
Costi politici sull'infrastruttura : ho preso in considerazione l'esecuzione di un controllo "infrastruttura" per ciascun metodo nell'esecuzione del test. Non ho avuto soluzione al timeout tranne che per sostituire il server di build. La burocrazia ha impedito la sostituzione del server.
Costo dei test delle unità di fissaggio : 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 delle unità 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 essere in grado di eseguire con precisione i test unitari. Ha senso dire che rendendo i dati più robusti, il test diventa più solido se dipende da questi dati. Certo, questo ha funzionato bene!
Costo della copertura, ovvero test di unità di scrittura per codice già esistente : c'era il problema della copertura del test unitario. C'erano migliaia di metodi che non avevano test unitari. Quindi, sarebbe necessario un numero considerevole di giorni uomo per crearli. Poiché sarebbe 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 intestinale qui è che i metodi statici erano un punto controverso su come sarebbe stato possibile determinare in modo univoco come un metodo statico specifico avesse fallito.
Costo delle versioni personalizzate : gli script Nant vanno solo oltre. Non sono così utili per, ad esempio, le build dipendenti da CMS 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 generazione per le esecuzioni di test orari e le build QA durante la notte. Mi rendo conto che questi non sono necessari in quanto un master di costruzione può eseguire queste attività manualmente al momento del rilascio, in particolare, con una band one man e una piccola build. Quindi, le build a step singolo non hanno giustificato l'uso di CI nella mia esperienza. Che dire delle build più complesse e multistep? Questi possono essere difficili da costruire, specialmente senza uno script Nant. Quindi, pur avendo creato uno, questi non avevano 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à del semaforo rosso.
Avendo dato una buona prova, credo che l'IC sia costoso e ci sia un sacco di lavoro ai margini invece di portare a termine il lavoro. È più economico impiegare sviluppatori esperti che non fanno confusione con grandi progetti piuttosto che introdurre e mantenere un sistema di allarme.
Questo è il caso anche se questi sviluppatori se ne vanno. Non importa se un bravo sviluppatore se ne va perché i processi che segue assicurano che egli scriva le specifiche dei requisiti, le specifiche di progettazione, rispetti le linee guida sulla codifica e commenta il suo codice in modo che sia leggibile. Tutto questo è recensito. Se questo non accade, il suo capo squadra non sta facendo il suo lavoro, che dovrebbe essere raccolto dal suo manager e così via.
Perché CI funzioni, non è sufficiente scrivere solo test unitari, tentare di mantenere una 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 persino auspicabile da una prospettiva aziendale. CI richiede molto lavoro per catturare una manciata di bug che il cliente potrebbe identificare in UAT o la società potrebbe essere pagata per il fixing come parte di un contratto di assistenza clienti quando il periodo di garanzia scade comunque.