Lo strumento che usiamo in Blexin come repository di codice per i nostri progetti è GitHub. In piena ottica DevOps, la maggior parte di questi progetti sono corredati di processi di automazione che ci aiutano a mantenere alta la qualità del codice, diminuendo il debito tecnico. Tra le varie pratiche che abbiamo adottato, ci sono quelle dedicate alla Continuous Integration, spesso collegate alle Pull Request (PR).
Nel nostro processo, il meccanismo di PR è fondamentale: si tratta in sostanza di una review sulle nuove feature sviluppate con l’intento di migliorarle e, allo stesso tempo, aiuta gli sviluppatori ad accrescere le proprie abilità tecniche.

In fase di creazione di una PR, o a seguito della sua chiusura, abbiamo impostato dei processi di automazione che ci aiutano a verificare se il codice compila correttamente e se i test presenti sono eseguiti con successo. Ad oggi, tali processi di automazione sono eseguiti attraverso Azure Pipelines che ha la possibilità di impostare dei trigger associati a determinati eventi (ad esempio: push, pull request) che scatenano l’avvio di una build.

A seguito dell’acquisizione di GitHub da parte di Microsoft e dell’introduzione delle GitHub Actions, mi sono chiesto se fosse possibile integrare alcuni processi già in atto come quelli di validazione di una PR direttamente su GitHub. In questo articolo, vi mostrerò come ho creato tale processo per Raptor, il layer di persistenza che sfrutta il nostro CMS WebRight.

Prima di procedere, occorre però fare una distinzione tra Azure Pipelines e GitHub Actions: ad oggi, queste ultime non dispongono di tutte le feature e la flessibilità che ritroviamo nelle prime. Sicuramente le Actions hanno un futuro radioso, ma per workflow articolati le Azure Pipelines restano la scelta più appropriata.
Altro aspetto da sottolineare è il prezzo: totalmente gratuito per repository pubblici mentre per i privati c’è un tier gratuito con una limitazione a 2000 minuti di build. Più che sufficienti per sperimentare e iniziare a prenderci la mano.

Di seguito, vi mostro come ho impostato una nostra Action. Una volta giunto su GitHub, ho selezionato la nuova tab nel repository che riporta la voce Actions (Figura 1):

Figura 1

Nella pagina che si apre, seleziono la voce New Workflow e mi trovo dinanzi alla pagina in Figura 2. Qui vengono proposti dei template di workflow già pronti, i quali si basano sulle tecnologie che ho nel nostro progetto (nel mio caso Angular).

Figura 2

Una volta selezionato il workflow Simple workflow, ho la possibilità di visualizzare un editor che mi consente di modificare il processo di build a mio piacimento e impostare gli step necessari. L’intero processo è definito usando YAML.

Figura 3

Seguendo la Figura 3 si possono evidenziare le seguenti sezioni:

1. Casella di testo per il nome del file YML, con la possibilità di dare un nome al nostro processo;
2. Un editor molto funzionale che, grazie anche all’intellisense, aiuta a definire i workflow;
3. Una sezione con una lista di possibili step da inserire nella action e una sezione relativa alla documentazione. Gli step che si possono importare nell’action derivano per la gran parte dalla community grazie alla presenza di un marketplace

All’interno del processo di build, oltre alle parti già preconfigurate, ho aggiunto i seguenti comandi

1. Installare l’Angular CLI sull’agent per eseguire la build del progetto;
2. Cambiare l’attuale directory spostandosi nella cartella del progetto;
3. Esecuzione di npm install;
4. Esecuzione della build con il comando npm run-script build.

Alcuni parametri interessanti nel processo sono:

• Sezione on (riga 2), dove è possibile definire i trigger del mio workflow. Nel mio caso, la action parte ad un push su determinati branch o alla creazione di una PR sul branch master;
• Sezione runs-on che definisce che tipologia di agent eseguirà la mia build. GitHub mette a disposizione diverse tipologie di agenti in base alle esigenze;
• Sezione matrix dove posso specificare combinazioni di framework su cui eseguire il mio workflow (ad esempio: diverse versioni di NodeJS)

Questo processo mi consente di compilare il codice e verificare se ci sono errori. Mi basta salvare il file YML con un commit in un branch ad-hoc che chiamo cicd e lasciare che parta la prima build come in Figura 4:

Figura 4

Riepilogando, nell’arco di pochi minuti sono riuscito a creare una build che mi consente di validare il codice che viene utilizzato e sottomesso tramite una operazione di push o in una PR. Nel caso della PR, in fase di creazione e alla fine dell’esecuzione dell’action il risultato sarà simile a questo:

Figura 5

Infine, un aspetto che mi piace molto delle Actions è che non sono solo legate alla validazione del codice, ma ne esistono molte che aiutano ad automatizzare task ripetitivi e molto spesso noiosi,come ad esempio quelli legati al mondo del ChatOps (Figura 6):

Figura 6

Happy Actions to everyone!