![XAMARIN DEVOPS
Nicolò Carandini [MVP]
@tpcware](https://image.slidesharecdn.com/xamarindevops-190331091715/85/Xamarin-DevOps-1-320.jpg)
Xamarin DevOps
- 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
- 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.
- 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