How to use the Azure DevOps pipeline to build a GithUb hosted Xamarin project

1. XAMARIN DEVOPS
Nicolò Carandini [MVP]
@tpcware

3. #DOAW19
Indice
• Pubblicare un progetto Xamarin in GitHub
• Organizzazione delle branch
• Utilizzare .gitignore per non rivelare i segreti
• Uso delle Pull Request per le collaborazioni
• Configurare CI/CD con Azure Pipelines for GitHub
• Verificare le PR con la Build prodotta dalla CI
• Pubblicare l’app negli Store

4. #DOAW19
PubblicareunprogettoXamarininGitHub
Vi sono molti modi per pubblicare una soluzione Xamarin.Forms, ma ove
possibile io consiglio di iniziare direttamente da GitHub:
1) Creazione progetto su GitHub, con:
• Licenza
• .gitignore di Visual Studio
• Readme
2) Clone del progetto da Visual Studio
3) Creazione del progetto in Visual Studio
4) Fare Commit del progetto e Sync per fare la push su GitHub

5. #DOAW19
Demo
Barcode Lab

6. #DOAW19
Organizzazionedellebranch
0.1.0
release
master
dev 1
dev 2
dev 3
0.2.0

7. #DOAW19
Utilizzare.gitignorepernonrivelareisegreti
Ricordatevi sempre che git mantiene tutta la storia, e quindi una volta
fatto un commit sul repository remote, è per sempre.
Molti servizi utilizzano delle chiavi che non devono essere rivelate, onde
evitare che un malintenzionato possa utilizzare tali servizi per una sua app
facendovi pagare a voi il consumo.
Per evitare il problema alla radice, basta utilizzare il file .gitignore

8. #DOAW19
…masenzalasciareglialtrisviluppatoriapiedi!
Mantenere solo in locale uno o più file senza farne il commit in remoto
ovviamente produce errori di compilazione per gli altri sviluppatori che lo
clonano o ne fanno il fork per contribuire.
La soluzione è semplice, se si seguono i seguenti passi:
1) Utilizzare un file contenente tutte le chiavi
2) Inserire valori fasulli nei contenuti delle chiavi
3) Fare la push del progetto, in modo tale che il file con le chiavi venga
effettivamente scritto nel repository remoto (ossia in GitHub)
4) Modificare il file .gitignore aggiungendo il path del file delle chiavi
5) Modificare localmente il file delle chiavi con i valori veri
6) Rifare la push del progetto, che a questo punto modificherà anche in
remoto il file .gitignore, ma non il file delle chiavi, che in remoto
rimarrà coi valori fasulli.

9. #DOAW19
Considerazionisull’usodi.gitignore
• Se da una parte posso consentire a sviluppatori terzi di collaborare al
progetto senza condividere con loro i miei segreti,
• Dall’altra sono necessariamente costretto a condividere il file delle
chiavi con i miei collaboratori in altro modo (invio il file delle chiavi a
quelli di cui mi fido, che sostituiranno manualmente in locale il file delle
chiavi fasulle con quello che gli ho mandato io).
• Da notare che anche se alcuni sviluppatori ora hanno in locale il file
delle chiavi vere, essi avranno anche ricevuto secondo le normali
modalità di sincronizzazione anche il file .gitignore da me modificato,
che contiene l’istruzione di ignorare il file delle chiavi, quindi il loro file
locale non sarà mai sincronizzato nel remoto, che è esattamente quello
che volevamo ottenere.

10. #DOAW19
UsodellePullRequestperlecollaborazioni
• Il vantaggio di utilizzare GitHub è quello di ricevere la collaborazione di
altri sviluppatori nello sviluppo del proprio progetto.
• Ciò si realizza attraverso la duplicazione (fork) del progetto dove è
possibile agire liberamente senza in alcun modo danneggiare o
modificare il progetto radice.
• E’ molto importante però che le modifiche siano circoscritte alla
soluzione di una specifica issue, già creata nel progetto radice, senza
aggiungere altre modifiche.
• Tali modifiche, circoscritte all’obiettivo preposto, formano il contenuto
di una Pull Request, più brevemente chiamata PR, che dovrà essere
controllata e verificata da chi ha la responsabilità di gestione del
progetto radice, visto che si tratta di accettare codice scritto da terzi e
che potrebbe introdurre più danni che vantaggi.

11. #DOAW19
LagestionedellePRrichiedenecessariamentelaCI
Mettetevi nei panni del gestore del progetto che riceve una PR.
Prima ancora di guardare il codice va verificato che il codice contenuto
nella PR non faccia fallire la build e non faccia fallire i test.
…perché tutti noi scriviamo i test a corredo dei nostri progetti, vero? 
Ed è qui che entra in gioco la Continuous Integration.

12. #DOAW19
AzurePipelinesforGitHub

13. #DOAW19
Setup
1. Navigare alla pagina del marketplace di GitHub di Azure Pipeline:
https://github.com/marketplace/azure-pipelines
2. Scorrere a fondo pagina e installare l’estensione:

14. #DOAW19
CreareunprogettosuAzureDevOps
L’estensione installata su GitHub consente di dialogare in automatico con
un progetto Azure DevOps, che va però creato manualmente e che si
consiglia di chiamare con lo stesso nome del progetto GitHub.
Il progetto dev’essere pubblico, visto che si collega ad un progetto GitHub
pubblico.

15. #DOAW19
Creareunabuildpipeline
1. Scegliere la sorgente dati:

16. #DOAW19
Creareunabuildpipeline
2. Autorizzare la connessione:

17. #DOAW19
Creareunabuildpipeline
3. Scegliere il repository:

18. #DOAW19
Creareunabuildpipeline
4. Scegliere un template:

19. #DOAW19
Creareunabuildpipeline
5. Salvare ed eseguire:

20. #DOAW19
PerchéèimportanteusareifilediconfigurazioneYAML
Molto semplicemente, perché essendo dei file contenuti nella soluzione,
partecipano a tutti i vantaggi del versioning Git.
Infatti salvando la configurazione della nostra Build pipeline, il file
azure-pipelines.yml è stato salvato nel nostro repository GitHub:

21. #DOAW19
Molteplicibuildpipelineperlostessoprogetto
E’ possibile aggiungere altre pipeline ed avere più file YAML nella propria
soluzione.
Ad esempio, si potrebbe avere una build pipeline legata al branch master
solo per controllare build e test dei commit e delle PR, e poi averne
un’altra che fa anche il deploy legata alla branch release.

22. #DOAW19
AggiungereTaskallabuildpipeline
E’ inoltre sempre possibile aggiungere ulteriori task alla pipeline, come ad
esempio aggiungere alla compilazione di Xamarin.Android anche quella di
Xamarin.iOS.
Peccato che una volta creato il file YAML, non vi sia più la possibilità di
utilizzare la configurazione guidata. Proprio per questo nell’editor del file
YAML, accanto al pulsante RUN c’è quello che apre la pagina Microsoft
Docs dedicata ad Azure Pipelines:

23. #DOAW19
ModificadelfileYAMLdaprogetto
Visto che la configurazione della Build Pipeline è definita tramite un file
che sta nel nostro progetto, e che una modifica di tale file produce
necessariamente una operazione di commit, è certamente possibile agire
direttamente dal nostro repository locale o da GitHub senza dover in alcun
modo andare sul progetto di Azure DevOps.
E d’altra parte questa è proprio la filosofia di DevOps, ovvero della
massima libertà di impostazione e gestione delle attività legate allo
sviluppo software, che una volta impostate non richiedono particolari
attenzioni ma semplicemente «funzionano».

24. #DOAW19
Demo
Azure Pipelines for GitHub

25. Grazieebuonaintegrazione
conAzureDevOps!
Nicolò Carandini
blog.tpcware.com
@TPCWare