Deploy di Angular SPA su GitHub Pages (e non solo) con GitHub Actions
Dopo aver scritto una sana e robusta (costituzione…ehm) applicazione Angular, arriva il momento di farne il deploy da qualche parte.
Angular CLI ci consente tramite il comando ng deploy la pubblicazione su svariate delle soluzioni presenti sul mercato come ad esempio Firebase, Netlify, GitHub Pages, etc…
Nel caso specifico tratteremo le GitHub Pages, che sono un’ottima e pratica soluzione per eseguire il deploy delle nostre applicazioni.
Per far si che le nostre applicazioni possano essere ospite in GitHub Pages, i processi sono molto semplici e sono elencati nel sito di riferimento.
Per applicazioni fatte con Angular le soluzioni più comode sono di certo due:
- Pubblicare tramite la Angular CLI con il comando ng deploy, utilizzando il pacchetto angular-cli-ghpages;
- Utilizzare le GitHub Actions per gestire l’intero processo di pubblicazione e perché no, occuparci anche un po’ di CI e di CD (e non è una supercazzola! :D).
angular-cli-ghpages
Grazie al pacchetto angular-cli-ghpages ed alla Angular CLI è possibile pubblicare in maniera davvero rapida l’applicazione su GitHub Pages, come indicato ampiamente nella documentazione del pacchetto stesso.
Non mi soffermerò quindi su questa soluzione che, oltre ad essere ben documentata, è molto pratica per lo più quando si esegue manualmente il processo di build direttamente dalla propria macchina di sviluppo, quindi in particolar modo quando non è necessario alcun automatismo di CI o CD.
Unica nota che mi permetto di sottolineare in questa modalità di pubblicazione, è la necessità di indicare il parametro base-ref in fase di compilazione:
ng deploy — base-href=/the-repositoryname/N.B. Il comando deploy permette di eseguire il processo di build del progetto in production mode.
GitHub Actions
Quando abbiamo bisogno di un controllo maggiore e, soprattutto, quando vogliamo gestire tutto il processo di CI e CD del nostro progetto, una delle soluzioni più comode ed integrate sono di certo le GitHub Actions!
Per farla molto breve, grazie alle GitHub Actions abbiamo la possibilità di automatizzare tutto il processo di test, build e deploy della nostra applicazione Angular ogni qualvolta sarà eseguito un nuovo commit su di un branch da noi scelto.
In realtà le GitHub Actions offrono molto più di questo, consentendo di creare workflow che possono risolvere un’infinità di casistiche!
Per avere una panoramica completa di ciò che offrono possiamo visitare il link https://github.com/features/actions.
Una semplice Action per la nostra Angular SPA
Nel nostro caso specifico ci occuperemo di una casistica piuttosto semplice ma che può offrire una serie interessante di spunti.
Ci occuperemo difatti di creare un workflow che, ogni qualvolta sarà eseguito un commit sul nostro branch master, eseguirà il processo di build della nostra applicazione e la successiva pubblicazione nel branch destinato alle GitHub Pages!
Nell’esempio useremo Redis Patterns Console come progetto al quale applicare il workflow delle GitHub Actions.
Redis Patterns Console è una console online interattiva (e reattiva), sviluppata con Angular, per provare e studiare Redis (il database in-memory più famoso al mondo!) ed i suoi più comuni pattern, il tutto direttamente da una web application e quindi senza dover installare e configurare nulla!
Una stella su GitHub ci farebbe davvero felici! :)
Ed ora si comincia…ma daremo chiaramente per scontato che:
- Abbiamo già eseguito login sul nostro account GitHub;
- Abbiamo già il repository del nostro progetto pubblicato su GitHub.
N.B. Nel nostro caso i print screen fanno riferimento ad un fork del repository.
Divideremo il processo per step, così da rendere il tutto più facile da seguire…iniziamo!
Step 1 - Creare un GitHub Token
- Cliccare sulla tab Settings del menù del nostro utente;
- Cliccare sulla voce Developer Settings del menù a sinistra;
N.B. Bella la mia foto eh? Sembro un orso bruno! :D
- Cliccare sulla voce Personal Access Token del menù a sinistra e, dopo aver cliccato il bottone Generate New Token, creare un token;
Step 2 - Creare una Secret Environment Variable nel Repository
- Ritornare sul repository e selezionare la tab Settings e selezionare la voce di menù Secrets;
- Dopo aver cliccato il bottone New Secret, creare un token con il nome ACCESS_TOKEN;
Step 3 - Creare il GitHub Actions Workflow
È finalmente il momento di creare la Action…
- Cliccare sulla tab Actions e cliccare sul link set up a workflow yourself;
N.B. Vengono messi a disposizione tantissimi ed eccellenti workflows già pronti da cui partire ma in questo caso faremo da noi… ;)
- Una volta aperto l’editor per il file sarà finalmente arrivato il momento in cui potremo scrivere la nostra Action, grazie al formato yml!
La Action difatti non sarà altro che una serie di istruzioni indicate nel file yml, che indicheranno a GitHub l’automatismo da realizzare e replicare ogni qualvolta sarà eseguita una determina azione sul nostro repository.
Ed ecco il contenuto del file da incollare nell’editor:
La struttura di questo workflow è piuttosto semplice e porta con se una struttura molto standard con qualche commento per i punti salienti utili nel nostro caso.
In ogni modo, tutti le chiavi standard possiamo eventualmente approfondirle al link https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow.
Come avrete notato, inoltre, sono state utilizzate per la nostra Action alcune ulteriori Actions, il che rende il tutto estremamente modulare e potente!
Ecco i links delle Actions utilizzate nel nostro workflow:
- https://github.com/actions/setup-node
- https://github.com/actions/checkout
- https://github.com/marketplace/actions/deploy-to-github-pages
Step 4 - Goditi l’automatismo della tua GitHub Action
Una volta eseguito il commit di questo file sarai pronto a godere degli automatismi appena creati.
Da questo momento in poi, ogni qualvolta il tuo branch master avrà un nuovo commit verrà eseguito l’automatismo ed il contenuto della GitHub Pages verrà aggiornato.
Una GitHub Action alternativa
Sono presenti già delle eventuali GitHub Actions pronte per fare ciò che abbiamo visto, come ad esempio:
Ritengo però che avere un minimo di controllo in più (data la ridottissima fatica nel farlo) può essere un’occasione per imparare qualcosa!
E le Environments Variables di Angular?
Beh, abbiate pazienza e nel prossimo articolo approfondiremo come poter rendere dinamici gli environments files di Angular, così da non dover esporre alcun dato pubblicamente sui nostri repository!
Conclusioni
Come potrete notare, il processo è estremamente semplice ma utile e potente e soprattutto potete tranquillamente riutilizzarlo per automatizzare il build di Angular anche per altre destinazioni.
Inoltre potrete chiaramente gestire tutte le altre fasi di CI e CD, come ad esempio l’esecuzione di una suite di test, monitoring sui risultati ottenuti dai vari step, etc…
Potete vedere il risulato di quanto eseguito dalla GitHub Action visitando direttamente il nostro progetto Redis Patterns Console, e magari cogliere l’occasione per imparare anche Redis!
Per suggerimenti (o aggiunte perché no!), critiche, insulti, lodi, donazioni di enormi quantità di denaro, partite a padel o consigli non serve altro che scrivere nei commenti!
