Integrazione continua

Saluti, colleghi! Stanco di forzare il tuo computer a costruire costantemente un progetto? Allora questo articolo fa per te! In questo articolo cercherò di presentare in modo breve e chiaro il materiale riguardante l’Integrazione Continua (di seguito semplicemente CI), risponderò a domande semplici come: “Cos’è?”, “Perché?” e perché?" e darò un esempio di un progetto di prova. Questo articolo è destinato a un utente esperto che abbia almeno familiarità con Build System: Maven , sappia come usare Git e sappia come inviare progetti a GitHub ;

"Cos'è l'integrazione continua?"

Vediamo cosa ci dice Wiki su questa domanda : L'integrazione continua (CI, inglese Continuous Integration) è una pratica di sviluppo software che consiste nell'unire copie di lavoro in un ramo di sviluppo principale comune più volte al giorno ed eseguire frequenti build automatizzate del progetto per le prime volte rilevamento di potenziali difetti e soluzioni ai problemi di integrazione. Spaventoso, non è vero? Proviamo a spiegare questo termine in parole semplici: l'integrazione continua è un sistema per la creazione e il test automatizzato di software con determinate configurazioni su determinate macchine al fine di rilevare bug e incompatibilità. Ok, nessun problema, l'abbiamo capito, ma sorge la seguente domanda logica:

Perché abbiamo bisogno della CI?

Immaginiamo solo che tu stia scrivendo un progetto di grandi dimensioni e che sia necessario aggiungere/modificare funzionalità. Lo scrivi con successo, scrivi test, lo avvii e tutto sembra andare bene, ma no. Ci sono situazioni in cui un cambiamento in una funzionalità influisce su un'altra, un'altra su una terza e così via, finché un bug non si insinua da qualche parte e si verifica un errore. Sì, puoi dire che molto probabilmente si tratta di un progetto mal progettato, e potresti avere ragione, ma cosa succede se non lo è, e queste connessioni dovrebbero davvero essere lì? E cosa succede se scrivi e crei un progetto più di una volta, come spesso accade? Hai eseguito dei test sulla funzionalità appena scritta e hanno dato un risultato positivo. Hai preso un impegno veloce, poi ti sei spinto da qualche parte e stai già pensando a come fumerai un sigaro a casa bevendo whisky costoso, ma no. Ahimè, il tuo collega o capo, non importa chi, dice che a causa del tuo impegno l'intera build è andata in crash. Dici con sconcerto che sei un programmatore, hai testato tutto. Ma spesso semplicemente non c'è tempo per testare costantemente l'intero progetto e hai testato solo la parte di codice a cui hai apportato modifiche e non l'intero assieme nel suo insieme. È qui che CI viene in nostro aiuto. Con ogni push su qualsiasi risorsa, CI creerà il tuo progetto da zero, eseguirà TUTTI i test e solo se tutti i test vengono superati e il progetto viene creato, la build riceverà lo stato di superamento . Altrimenti avrai l'opportunità di tornare indietro e vedere cosa è andato storto. Quindi è il momento di porsi la domanda "Perché questo e non altrimenti?" e dai un'occhiata all'implementazione del software. Esempio Come ho già detto, l'articolo è destinato a coloro che hanno familiarità con Maven e Git. Pertanto, spero che tu sappia come e cosa faccio oltre a configurare CI, ecc.

1. Innanzitutto, creiamo un semplice progetto di test Maven e creiamo una classe al suo interno che stampi "Hello World!" ed esegue alcune semplici operazioni e scriviamo il test più semplice per questa classe.

   Di conseguenza, dovremmo avere una struttura di progetto primitiva:

   Tutte le fonti saranno sul mio GitHub. Non importa cosa scrivi nel tuo Main e quali test ci saranno.

2. Portiamo il nostro progetto su GitHub.

3. Ora arriva la parte divertente. Da CI, ho scelto Travis CI per la sua disponibilità e affidabilità. Travis utilizza GitHub per ospitare il suo codice sorgente.

   Quindi, vai al sito Web di Travis CI e accedi tramite GitHub. Nel profilo colleghiamo il nostro progetto:

   Tutto è pronto per il montaggio ad ogni spinta, ma la domanda è: COME montare?

4. Torniamo alla nostra amata IDEA e creiamo un file .travis.yml

   Questo file è responsabile della configurazione della build di Travis. Diamo un'occhiata all'impostazione più popolare:

   • È necessario specificare la lingua in cui viene realizzato il progetto;
   • Specificare il percorso delle directory per rendere la compilazione più veloce;
   • Specificare il metodo di notifica dell'assemblaggio riuscito o non riuscito.

   Ecco come dovrebbe apparire una tipica configurazione di Travis:

   # https://docs.travis-ci.com/user/languages/java/
   language: java
   jdk: oraclejdk9
   
   # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects
   cache:
     directories:
     - $HOME/.m2
   
   # Notifications https://docs.travis-ci.com/user/notifications/
   notifications:
     email:
       recipients:
         - qThegamEp@gmail.com
       on_success: always # default: change
       on_failure: always # default: always

   Ho aggiunto commenti, con collegamenti, per chiarezza.

5. Spingiamo nuovamente su GitHub e apriamo il sito Web di Travis , selezioniamo il progetto e monitoriamo la build. Di conseguenza, riceviamo una notifica relativa a una build riuscita:

   Inoltre sul sito possiamo vedere un badge con l'avvenuto assemblaggio del nostro progetto, che possiamo inserire nel nostro README.md:

Link utili:

• Il mio progetto di prova che puoi visualizzare/scaricare se non capisci qualcosa;

• In realtà il sito web stesso di Travis CI ;

• Tutorial sul sito ufficiale sulla configurazione e l'utilizzo di Travis CI;

• Bel video ;

• Un altro tutorial ;

• Articolo successivo

Potrebbero esserci errori ed omissioni nel testo. Grazie per l'attenzione!