Come configurare la continuous integration
Scopri come adottare la continuous integration e i test automatizzati in 5 passaggi.
Sten Pittet
Scrittore collaboratore
La continuous integration (CI) è una best practice agile e DevOps in cui gli sviluppatori integrano le modifiche al codice in anticipo e spesso nel branch o nel repository di codice principale. L'obiettivo è evitare che il processo di integrazione diventi un inferno, tra infinite attese della fine dei progetti e sprint finali per unire il lavoro di tutti gli sviluppatori. Poiché automatizza la distribuzione, aiuta i team a soddisfare i requisiti aziendali, migliorare la qualità del codice e aumentare la sicurezza.
Uno dei principali vantaggi dell'adozione della CI è che ti farà risparmiare tempo durante il tuo ciclo di sviluppo identificando e risolvendo precocemente i conflitti. È anche un ottimo modo per ridurre il tempo necessario per correggere bug e regressioni ponendo maggiore enfasi sull'importanza di disporre di una buona suite di test. Infine, aiuta a condividere una migliore comprensione del codebase e delle funzionalità che stai sviluppando per i tuoi clienti.
Il primo passo nel tuo viaggio verso la continuous integration: configurare i test automatizzati.
Come iniziare a utilizzare i test automatizzati
Comprendere i diversi tipi di test
Per ottenere tutti i vantaggi della CI, dovrai automatizzare i tuoi test per poterli eseguire per ogni modifica apportata al repository principale. Insistiamo nell'eseguire test su ogni branch del tuo repository e non concentrarci solo sul branch principale. In questo modo, sarai in grado di rilevare i problemi in anticipo e ridurre al minimo le interruzioni per il tuo team.
Esistono molti tipi di test implementati, ma non è necessario fare tutto in una volta se hai appena iniziato. Puoi iniziare in piccolo con unit test e lavorare per estendere la tua copertura nel tempo.
- Gli unit test hanno un ambito ristretto e in genere verificano il comportamento di singoli metodi o funzioni.
- I test di integrazione garantiscono che più componenti si comportino correttamente insieme. Possono essere previsti lezioni e test di integrazione con altri servizi.
- I test di accettazione sono simili ai test di integrazione, ma si concentrano sui casi aziendali piuttosto che sui componenti stessi.
- I test dell'interfaccia utente verificheranno che l'applicazione funzioni correttamente dal punto di vista dell'utente.
Scopri la soluzione
Creare e gestire software con Open DevOps
Materiale correlato
Scopri di più sui test automatizzati
Non tutti i test sono uguali e puoi visualizzare i compromessi che raggiungerai con la piramide del test sviluppata da Mike Cohn.
Gli unit test sono veloci ed economici da implementare poiché per lo più controllano piccoli frammenti di codice. D'altra parte, i test dell'interfaccia utente saranno complessi da implementare e lenti da eseguire poiché spesso richiedono l'avvio di un ambiente completo e più servizi per emulare i comportamenti del browser o dei dispositivi mobili. Per questo motivo, potresti voler limitare il numero di test complessi dell'interfaccia utente e fare affidamento su unit test validi alla base per ottenere una build veloce e fornire feedback agli sviluppatori il prima possibile.
Esegui i tuoi test automaticamente
Per adottare la continuous integration, dovrai eseguire i tuoi test su ogni modifica che viene respinta al branch principale. Per farlo, avrai bisogno di un servizio in grado di monitorare il tuo repository ed essere in ascolto di nuovi push al codebase. Sono disponibili molte soluzioni tra cui puoi scegliere, sia locali che nel cloud. Devi considerare quanto segue per scegliere il tuo server:
- Dov'è ospitato il tuo codice? Il servizio di CI può accedere al codebase? Hai una restrizione speciale su dove può risiedere il codice?
- Di che sistema operativo e risorse hai bisogno per la tua applicazione? Il tuo ambiente applicativo è supportato? Puoi installare le dipendenze giuste per compilare e testare il tuo software?
- Di quante risorse hai bisogno per i tuoi test? Alcune applicazioni cloud potrebbero presentare restrizioni sulle risorse da usare. Se il tuo software consuma molte risorse, potresti voler ospitare il tuo server di CI protetto da firewall.
- Quanti sviluppatori sono presenti nel tuo team? Nell'ambito delle sperimentazioni del tuo team con la CI, verranno respinte molte modifiche al repository principale. Affinché gli sviluppatori ottengano un feedback rapido, devi ridurre il tempo di coda per le build e vorrai utilizzare un servizio o un server che offra la giusta concorrenza.
In passato, in genere era necessario installare un server di CI separato come Bamboo o Jenkins, mentre ora sono disponibili soluzioni cloud molto più semplici da adottare. Ad esempio, se il codice è ospitato su Bitbucket Cloud, puoi utilizzare la funzione Pipelines nel repository per eseguire test su ogni push senza la necessità di configurare un server o agenti di compilazione separati e senza restrizioni sulla concorrenza.
image: node:4.6.0 pipelines: default: - step: script: - npm install - npm testEsempio di configurazione per testare un repository Javascript con Bitbucket Pipelines.
Usare la code coverage per trovare codice non testato
Una volta adottati i test automatizzati, sarebbe opportuno abbinarli a uno strumento di code coverage del test per avere un'idea della quantità di codebase coperta dalla suite di test.
È bene puntare a una copertura superiore all'80%, ma attenzione a non confondere un'alta percentuale di copertura con una buona suite di test. Uno strumento di code coverage ti aiuterà a trovare codice non testato, ma ciò che conta davvero è la qualità dei tuoi test.
Se hai appena iniziato, non avere fretta di raggiungere una copertura del 100% del tuo codebase, ma utilizza uno strumento di code coverage del test per scoprire le parti critiche della tua applicazione non ancora testate e inizia da lì.
Il refactoring è un'opportunità per aggiungere test
Se stai per apportare modifiche significative alla tua applicazione, dovresti iniziare scrivendo test di accettazione sulle funzionalità che potrebbero essere interessate. Questo ti fornirà una rete di sicurezza per garantire che il comportamento originale non sia stato alterato dopo aver sottoposto a refactoring il codice o aggiunto nuove funzionalità.
Fattori critici di successo nell'adozione della continuous integration
Sebbene l'automazione dei test sia una parte fondamentale della CI, non è sufficiente. Potrebbe essere necessario cambiare la cultura del tuo team per assicurarti che gli sviluppatori non lavorino per giorni su una funzionalità senza eseguire il merge delle modifiche al branch principale e dovrai rafforzare la cultura di una green build.
Integrazione anticipata e frequente
Che tu stia utilizzando uno sviluppo basato su trunk o branch di funzioni, è importante che gli sviluppatori integrino le loro modifiche il prima possibile nel repository principale. Se lasci che il codice rimanga su un branch o sulla workstation per sviluppatori per troppo tempo, rischierai di avere troppi conflitti da esaminare nell'ambito del merge al branch principale.
L'integrazione anticipata consente di ridurre l'ambito delle modifiche, per agevolare la comprensione di eventuali conflitti. Inoltre, semplifica la condivisione delle conoscenze tra gli sviluppatori, in quanto otterranno modifiche più assimilabili.
Qualora apportassi modifiche che possono influire su una funzionalità esistente, potrai utilizzare i tag delle funzionalità per disattivare le modifiche in produzione fino al completamento del lavoro.
Mantenere la build sempre integra
Se uno sviluppatore interrompe la build per il branch principale, correggerla diventerà la priorità principale. Più modifiche vengono introdotte mentre la build è interrotta, più sarà difficile capire cosa l'ha interrotta, rischiando di introdurre più errori.
Vale la pena dedicare del tempo alla tua suite di test per verificare che restituisca velocemente eventuali errori per fornire velocemente un feedback allo sviluppatore che ha apportato le modifiche. Puoi suddividere i tuoi test in modo che quelli veloci (ad esempio gli unit test) vengano eseguiti prima dei test a esecuzione prolungata. Se la suite di test impiega sempre molto tempo a restituire errori, gli sviluppatori perderanno molto tempo perché dovranno cambiare contesto per tornare al lavoro precedente e correggerlo.
Non dimenticare di impostare le notifiche per assicurarti che gli sviluppatori vengano avvisati quando la build si interrompe e fai un ulteriore passo avanti mostrando lo stato dei tuoi branch principali su una dashboard in cui sia visibile a tutti.
Scrivere test nell'ambito delle tue story
Infine, dovrai assicurarti che ogni funzionalità sviluppata abbia test automatizzati. Ti potrà sembrare di rallentare lo sviluppo, ma in realtà, questo ridurrà drasticamente il tempo che il tuo team impiega per correggere la regressione o i bug introdotti in ogni iterazione. Potrai anche apportare modifiche alla tua codebase in tutta sicurezza poiché la tua suite di test sarà in grado di assicurarsi rapidamente che tutte le funzionalità sviluppate in precedenza funzionino come previsto.
Per scrivere buoni test, dovrai assicurarti che gli sviluppatori siano coinvolti nelle prime fasi della definizione delle story degli utenti. Questo è un ottimo modo per comprendere meglio i requisiti aziendali e facilitare il rapporto con i responsabili di prodotto. Puoi anche iniziare scrivendo i test prima di implementare il codice che li soddisferà.
Scrivere test nell'ambito della correzione dei bug
Che tu abbia già una codebase o abbia appena iniziato, sicuramente si verificheranno dei bug durante le tue versioni. Assicurati di aggiungere dei test quando li risolvi per evitare che si ripetano.
La CI consentirà ai tecnici dedicati al controllo di qualità di migliorare la qualità
Un altro ruolo che cambierà con l'adozione della CI e dell'automazione è quello del tecnico dedicato al controllo di qualità. Non avranno più bisogno di testare manualmente le funzionalità basilari delle applicazioni e potranno dedicare più tempo a fornire strumenti per supportare gli sviluppatori e aiutarli ad adottare le giuste strategie di test.
Non appena inizierai ad adottare la continuous integration, i tecnici dedicati al controllo di qualità potranno focalizzarsi sulla semplificazione dei test tramite strumenti e set di dati migliori, aiutando al contempo gli sviluppatori a migliorare la loro capacità di scrittura di codice. Saranno ancora previsti alcuni test esplorativi per i casi d'uso complessi, ma si tratterà di una parte meno importante del loro lavoro.
5 passaggi per configurare la continuous integration
Ora dovresti avere un'idea dei concetti alla base della continuous integration, che possiamo riassumere in questo modo:
- Iniziare a scrivere test per le parti critiche della codebase.
- Ottenere un servizio di CI per eseguire automaticamente i test su ogni push nel repository principale.
- Assicurarsi che il team integri le modifiche ogni giorno.
- Correggere la build non appena si interrompe.
- Scrivere test per ogni nuova story che viene implementata.
Anche se può sembrare facile, richiederà un vero impegno da parte del team per fare in modo che sia efficace. All'inizio sarà necessario rallentare i rilasci e servirà il consenso degli owner di prodotto per assicurarti che non spingano gli sviluppatori a distribuire le funzionalità senza test.
Il nostro consiglio è di iniziare in piccolo con semplici test per abituarsi alla nuova routine prima di passare all'implementazione di una suite di test più complessa, che potrebbe essere difficile da gestire.
Scopri la continuous integration con Bitbucket Pipelines. E, se vuoi creare una toolchain DevOps, assicurati di dare un'occhiata a Open DevOps, che include integrazioni con i fornitori e le app del Marketplace leader del settore.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Community DevOps
Leggi il blog
