Un approccio moderno a

Integrazione Continua e
Distribuzione Continua
Daniele De Marchi
demarchi.daniele001@spes.uniud.it

30 Luglio 2021
 SCALETTA

DevOps CI con le Github Actions

Una rapida introduzione a DevOps e
alle procedure fondamentali
01 04 Cosa sono le Github Actions e
come abilitano la CI

Integrazione Continua CD in Heroku

Perchè utilizzarla, come funziona e i
vantaggi di adottare la Continuous
02 05 Gli strumenti per la CD offerti da
Heroku, mostrata tramite una
Integration (CI) pipeline di delivery

Distribuzione Continua Demo

Definizione, come funziona e i
vantaggi di adottare la il Continuous
03 06 Una semplice api realizzata con
Node.js
Delivery (CD)

2
DevOps
Il termine DevOps deriva dalla contrazione di development,
"sviluppo", e operations, qui simile a "messa in produzione" o
"deployment".

DevOps è un metodologia di sviluppo software che punta alla

comunicazione, collaborazione e integrazione tra sviluppatori e
addetti alle operations della information technology (IT).

In una realtà strutturata i componenti software vengono installati

in infrastrutture grandi e complesse.
È quindi necessario coordinare il lavoro di chi scrive il software
(development) con quello di chi gestisce l’infrastruttura
(operations).

3
DevOps (2)
Secondo il modello DevOps, i team dedicati a sviluppo e produzione non agiscono più
separatamente: i due team vengono fusi in un'unità in cui i tecnici sono attivi lungo
tutto il ciclo di vita dell'applicazione, da sviluppo e testing a distribuzione e
produzione.

I team si affidano all'automatizzazione per velocizzare processi manuali.

Le tecnologie e gli strumenti impiegati aiutano i team a far funzionare ed evolvere le
applicazioni in modo rapido e affidabile.
Questi strumenti aiutano i tecnici anche a portare a termine attività che normalmente
avrebbero richiesto l'attenzione di altre unità aziendali.

4
Le procedure di DevOps
I team applicano l'approccio DevOps implementando alcune procedure nell'intero
ciclo di vita dell'applicazione.

Le più comuni procedure DevOps sono 5 (6):

● Integrazione continua e Distribuzione continua (CI/CD)
● Controllo della versione
● Approccio di sviluppo Agile
● Infrastruttura come codice
● Monitoraggio e accessi
● (microservizi)

5
Le procedure di DevOps (2)
Controllo della versione:
Consiste nella procedura di gestione del codice in versioni diverse, ovvero nel controllo delle
revisioni e della cronologia delle modifiche per semplificare la revisione e il ripristino del
codice.

Approccio di sviluppo Agile:

DevOps e Agile non sono due metodi di sviluppo diversi ma sono uno il miglioramento
dell’altro. DevOps estende il metodo Agile oltre al codice, applicandolo all'intero processo.

Infrastruttura come codice:

Tutte le distribuzioni del server, i servizi cloud e la configurazione associata sono archiviati in
un insieme di file di configurazione modificabile centralmente.

Monitoraggio e accessi:
Le aziende tengono sotto controllo i parametri e i log per scoprire in che modo le prestazioni
di applicazione e infrastruttura influiscono sull'esperienza dell'utente finale.

6
Integrazione Continua
Perché è necessaria l'integrazione continua?
L'integrazione del codice eseguita poco frequentemente porta a numerose difficoltà:
● Processo di integrazione dispendioso in termini di tempo.
● Maggiori merge conflict.
● Codice nel repository centrale non aggiornato.
● Testabilità ridotta.

Come funziona l'integrazione continua?

Gli sviluppatori eseguono i commit in modo più frequente in un repository condiviso e
impiegano un sistema di controllo della versione.
Un servizio di integrazione continua crea automaticamente una build e avvia unit test sulle
modifiche più recenti del codice per individuare immediatamente qualsiasi errore.

7
 Vantaggi dell’Integrazione Continua

Maggiore produttività per Bug individuati e risolti con

gli sviluppatori maggiore prontezza Aggiornamenti più rapidi

Maggior la produttività Aumentando la frequenza L'integrazione continua

liberando gli sviluppatori del testing, è più facile consente di rilasciare
dalle attività manuali come individuare aggiornamenti in modo più
il merge e il testing del tempestivamente e rapido e con maggiore
codice. risolvere i bug. frequenza.

8
Distribuzione Continua
La distribuzione continua estende l'integrazione continua distribuendo tutte le modifiche al
codice all'ambiente di testing e/o di produzione, dopo la fase di creazione di build.

Consente agli sviluppatori di automatizzare il testing andando oltre gli unit test.
Queste prove possono includere test dell'interfaccia, test di caricamento, test di integrazione,
test di affidabilità delle API e così via.

Ogni modifica al codice viene applicata a una build, testata e inoltrata in un ambiente di
testing (non in produzione) o temporaneo. La decisione finale per implementare il nuovo
software nell'ambiente di produzione attivo dipende solitamente dal capo progetto.

9
 Vantaggi della Distribuzione Continua

Processo di rilascio del Bug individuati e risolti con

software automatizzato maggiore prontezza Aggiornamenti più rapidi

La distribuzione continua Possibilità di eseguire Se la distribuzione continua

consente al team di testare, ulteriori test dopo la fase di viene implementata
preparare e applicare le integrazione, come test di correttamente, si avrà
modifiche al codice per carico, disponibilità, sempre a disposizione una
l'inoltro in produzione in affidabilità. build temporanea pronta
modo più efficiente e per la distribuzione, che ha
veloce. già passato un processo di
testing standardizzato.

10
 SCALETTA

DevOps CI con le Github Actions

Una rapida introduzione a DevOps e
alle procedure fondamentali
01 04 Cosa sono le Github Actions e
come abilitano la CI

Integrazione Continua CD in Heroku

Perchè utilizzarla, come funziona e i
vantaggi di adottare la Continuous
02 05 Gli strumenti per la CD offerti da
Heroku, mostrata tramite una
Integration (CI) pipeline di delivery

Distribuzione Continua Demo

Definizione, come funziona e i
vantaggi di adottare la il Continuous
03 06 Una semplice api realizzata con
Node.js
Delivery (CD)

11
Github Actions
Le Github actions sono dei flussi di lavoro event-driven, ovvero eseguono una serie di
comandi solo dopo l’attivazione di un predeterminato trigger: è possibile, ad esempio,
eseguire uno script di test quando viene creata una pull-request in un determinato branch del
repository.

I componenti di una Github Action sono i seguenti:

Workflow: procedura automatizzata per una repository. I workflow sono costituiti da
uno o più jobs, e sono attivati da eventi.
Events: Evento che attiva un workflow: può essere ad esempio una pull request o un
merge in un determinato branch.
Jobs: Un job è costituito da uno o più step e i vari jobs specificati in un workflow
vengono eseguiti in sequenza. 2 esempi tipici di jobs, eseguiti in sequenza,
sono la compilazione dell’applicazione e il lancio di uno script di test.
Steps: uno step è un comando individuale eseguito dal runner: può essere un
comando shell oppure un’ action.
Actions: le azioni sono dei singoli comandi (shell) combinati insieme per creare un job.
Runners: un runner è il server in cui viene eseguita l’action. È possibile usufruire dei server
messi a disposizione direttamente da Github, oppure specificare un server
personale. I runner offerti da Github sono basati su sistema operativo Ubuntu
Linux, Microsoft Windows oppure macOS.

12
Github Actions (2)
Per specificare una Github Action è sufficiente creare un file in formato YAML nella cartella
.github/workflows del repository.

13
Esecuzione Github Action

14
Esecuzione Github Action fallimento test

15
CD con Heroku
Heroku è una piattaforma cloud di hosting per applicazioni web.

Heroku mette a disposizione 3 principali funzionalità che semplificano la

distribuzione continua di un’applicazione.

Integrazione con Github:

È possibile collegare un’applicazione direttamente con un repository Github, per
rendere più semplice il deploy dell’applicazione.

Review Apps:
Applicazioni temporanee ed isolate, create in automatico quando viene aperta una
pull request in uno specificato branch del repository Github. In questo modo è
possibile testare singolarmente le modifiche apportate al codice.

Pipelines:
Una pipeline è composta da un gruppo di applicazioni Heroku, che condividono la
stessa codebase (stesso progetto). Ogni applicazione nella pipeline rappresenta uno
dei seguenti stadi nel flusso del continuous delivery: Development, (Review), Staging,
Production.

16
CD con Heroku (2)
Il tipico utilizzo di una pipeline di delivery è composto da 5 passi:

1. Uno sviluppatore apre una pull request su github, per apportare delle
modifiche al codice dell’applicazione.

2. Automaticamente, Heroku crea una review app, che permette agli sviluppatori
di testare e valutare i cambiamenti apportati, in un ambiente isolato.

3. Una volta verificato il corretto funzionamento delle modifiche, la pull request

viene accettata, e viene effettuato il merge del branch di sviluppo con il master
branch dell’applicazione.

4. Viene effettuato automaticamente il deploy del master branch

nell’applicazione di staging della pipeline di Heroku. In questa fase si andranno
ad effettuare ulteriori test prima di portare le modifiche nel server di
produzione.

5. Se tutto funziona correttamente, uno sviluppatore (solitamente il capo

progetto) promuove i cambiamenti dall’app di staging all’app di produzione,
rendendoli disponibili agli utenti finali.

17
Pipeline

18
DEMO

19
Conclusioni
Github Actions e Heroku CD sono 2 semplici strumenti che permettono di
realizzare una completa pipeline di CI/CD.
Per progetti di maggiori dimensioni, o per realizzare pipeline più elaborate e
personalizzate, esistono molti strumenti professionali come Azure DevOps
(Microsoft) oppure gli strumenti della suite Atlassian.

Vantaggi nell’adottare CI/CD:

● Maggior produttività generale.
● Testing più efficace.
● Maggior facilità nel distribuire nuove versioni dell’applicazione.
● Strumenti ben integrati con piattaforme Cloud.

Svantaggi:
● Strumenti per CI/CD difficili da configurare se non si sfruttano servizi
in cloud.
● Rischio di vendor lock-in.
● Rischio di realizzazione errata della pipeline (fidarsi troppo della
pipeline).

20
 Riferimenti e Credits

● Amazon AWS. (s.d.). AWS e DevOps.

Tratto da aws.amazon.com: https://aws.amazon.com/it/devops/
● Github. (s.d.). Documentazione ufficiale Github Action.
Tratto da github.com: https://docs.github.com/en/actions
● Heroku. (s.d.). Heroku official docs.
Tratto da heroku.com: https://devcenter.heroku.com/categories/reference
● Microsoft Azure. (s.d.). Che cos'è DevOps?
Tratto da azure.microsoft.com: https://azure.microsoft.com/it-it/overview/what-is-devops/

● Presentation template by Slidesgo

● Icons by Flaticon

21