Integrazione continua - Riduzione dei rischi
Ci sono possibilità che le cose vadano storte in un progetto. Praticando efficacemente CI, scopri cosa succede ad ogni passo lungo il percorso, piuttosto che in seguito, quando il progetto è nel ciclo di sviluppo. CI ti aiuta a identificare e mitigare i rischi quando si verificano, rendendo più facile valutare e riferire sullo stato di salute del progetto sulla base di prove concrete.
Questa sezione si concentrerà sui rischi che possono essere evitati utilizzando l'integrazione continua.
In qualsiasi progetto, ci sono molti rischi che devono essere gestiti. Eliminando i rischi nelle prime fasi del ciclo di vita dello sviluppo, ci sono minori possibilità che questi rischi si trasformino in problemi in seguito, quando il sistema diventa effettivamente operativo.
Rischio 1 - Mancanza di software distribuibile
“It works on my machine but does not work on another”- Questa è probabilmente una delle frasi più comuni riscontrate in qualsiasi organizzazione di software. A causa del numero di modifiche apportate quotidianamente alle build del software, a volte c'è poca fiducia sul fatto che la build del software funzioni effettivamente o meno. Questa preoccupazione ha i seguenti tre effetti collaterali.
Poca o nessuna fiducia nella possibilità di costruire il software.
Lunghe fasi di integrazione prima della consegna del software internamente (cioè, team di test) o esternamente (cioè, cliente), durante le quali non viene fatto altro.
Incapacità di produrre e riprodurre build testabili.
Soluzione
Eliminazione dello stretto accoppiamento tra IDE e processi di compilazione. Utilizzare una macchina separata esclusivamente per l'integrazione del software. Assicurati che tutto ciò di cui hai bisogno per creare il software sia contenuto nel repository di controllo della versione. Infine, crea un sistema di integrazione continua.
Il server Continuous Integration può controllare le modifiche nel repository di controllo della versione ed eseguire lo script di compilazione del progetto quando rileva una modifica al repository. La capacità del sistema di integrazione continua può essere aumentata per includere la compilazione di eseguire test, eseguire ispezioni e distribuire il software negli ambienti di sviluppo e test; in questo modo hai sempre un software funzionante.
“Inability to synchronize with the database”- A volte gli sviluppatori non sono in grado di ricreare rapidamente il database durante lo sviluppo e quindi trovano difficile apportare modifiche. Spesso ciò è dovuto a una separazione tra il team del database e il team di sviluppo. Ogni squadra sarà concentrata sulle proprie responsabilità e avrà poca collaborazione tra di loro. Questa preoccupazione ha i seguenti tre effetti collaterali:
Paura di apportare modifiche o refactoring del database o del codice sorgente.
Difficoltà nel popolare il database con diversi set di dati di test.
Difficoltà nel mantenere gli ambienti di sviluppo e test (ad es. Sviluppo, Integrazione, QA e Test).
Soluzione
La soluzione al problema precedente è garantire che il posizionamento di tutti gli artefatti del database nel repository di controllo della versione venga eseguito. Ciò significa tutto ciò che è necessario per ricreare lo schema ei dati del database: sono necessari script di creazione del database, script di manipolazione dei dati, stored procedure, trigger e qualsiasi altra risorsa del database.
Ricostruisci il database e i dati dal tuo script di build, rilasciando e ricreando il tuo database e le tabelle. Successivamente, applica le stored procedure e i trigger e, infine, inserisci i dati di test.
Testa (e ispeziona) il tuo database. In genere, utilizzerai i test dei componenti per testare il database ei dati. In alcuni casi, dovrai scrivere test specifici del database.
Rischio 2 - Scoperta di difetti nelle ultime fasi del ciclo di vita
Poiché ci sono così tante modifiche che avvengono frequentemente da più sviluppatori al codice sorgente, ci sono sempre possibilità che un difetto possa essere introdotto nel codice che potrebbe essere rilevato solo in una fase successiva. In questi casi, ciò può causare un grande impatto perché più tardi il difetto viene rilevato nel software, più costoso diventa rimuovere il difetto.
Soluzione
Regression Testing- Questo è l'aspetto più importante di qualsiasi ciclo di sviluppo software, test e test di nuovo. In caso di modifiche importanti al codice software, è assolutamente obbligatorio assicurarsi che tutti i test vengano eseguiti. E questo può essere automatizzato con l'aiuto del server Continuous Integration.
Test Coverage- Non ha senso eseguire il test se i casi di test non coprono l'intera funzionalità del codice. È importante assicurarsi che i test case creati per testare l'applicazione siano completi e che tutti i percorsi del codice siano testati.
Ad esempio, se si dispone di una schermata di accesso che deve essere testata, non è possibile disporre di uno scenario di test con lo scenario di un accesso riuscito. È necessario disporre di un test case negativo in cui un utente immette una diversa combinazione di nomi utente e password e quindi è necessario vedere cosa succede in tali scenari.
Rischio 3 - Mancanza di visibilità del progetto
I meccanismi di comunicazione manuale richiedono molto coordinamento per garantire la diffusione delle informazioni sul progetto alle persone giuste in modo tempestivo. Appoggiarsi allo sviluppatore accanto a te e fargli sapere che l'ultima build è sul Drive condiviso è piuttosto efficace, ma non si adatta molto bene.
E se ci sono altri sviluppatori che hanno bisogno di queste informazioni e sono in pausa o altrimenti non disponibili? Se un server non funziona, come vieni avvisato? Alcuni credono di poter mitigare questo rischio inviando manualmente un'e-mail. Tuttavia, ciò non può garantire che le informazioni vengano comunicate alle persone giuste al momento giusto perché potresti accidentalmente escludere le parti interessate e alcuni potrebbero non avere accesso alla loro posta elettronica in quel momento.
Soluzione
La soluzione a questo problema è di nuovo il server Continuous Integration. Tutti i server CI hanno la possibilità di avere email automatiche da attivare ogni volta che le build falliscono. Con questa notifica automatica a tutte le principali parti interessate, è inoltre garantito che tutti siano a bordo di quello che è lo stato attuale del software.
Rischio 4 - Software di bassa qualità
Ci sono difetti e poi ci sono potenziali difetti. Si possono presentare potenziali difetti quando il software non è ben progettato o se non segue gli standard del progetto o è complesso da mantenere. A volte le persone si riferiscono a questo come a odori di codice o di progettazione, "un sintomo che qualcosa potrebbe essere sbagliato".
Alcuni credono che il software di qualità inferiore sia solo un costo del progetto differito (dopo la consegna). Può essere un costo del progetto differito, ma porta anche a molti altri problemi prima di consegnare il software agli utenti. Codice eccessivamente complesso, codice che non segue l'architettura e codice duplicato: tutti di solito portano a difetti nel software. Trovare questi odori di codice e di progettazione prima che si manifestino in difetti può far risparmiare tempo e denaro e può portare a software di qualità superiore.
Soluzione
Ci sono componenti software per eseguire un controllo di qualità del codice che può essere integrato con il software CI. Questa operazione può essere eseguita dopo la creazione del codice per garantire che il codice sia effettivamente conforme alle linee guida di codifica appropriate.