Introduzione

Nel precedente articolo abbiamo introdotto brevemente il servizio Web App di Azure e i metodi più comuni per crearla (link).

Il servizio Web App consente di creare, distribuire e ridimensionare rapidamente applicazioni Web, per dispositivi mobili e API di livello aziendale, in qualsiasi piattaforma e soddisfare rigorosi requisiti di prestazioni, scalabilità, sicurezza e conformità usando al contempo una piattaforma completamente gestita e manutenzionata.

Da questo articolo iniziamo ad approfondire le caratteristiche del servizio Web App partendo dal Centro distribuzione e dai metodi di continuos deployment del codice sorgente dell’applicazione web che stiamo sviluppando.

Per accedere al Centro distribuzione:

• Nel portale di Azure cercare e selezionare Servizi app (App Services).
• Selezionare il servizio app che di desidera distribuire.
• Nella pagina dell’app selezionare Centro di distribuzione (Deployment Center) nel menu a sinistra.

Componenti per la distribuzione

I tre componenti principali per la distribuzione del codice nel servizio Web App sono:

• L’origine di distribuzione:Un’origine di distribuzione è il percorso dove risiede il codice dell’applicazione. Di solito l’origine di distribuzione è un repository ospitato dal software di controllo versione utilizzato dal team (ad esempio GitHub, BitBucket o Azure Repos). In scenari in cui il codice risiede su un computer locale o sul cloud, il servizio Web App supporta anche cartelle su OneDrive o Dropbox come origine di distribuzione.
• Pipeline di compilazione:Dopo aver scelto l’origine di distribuzione, il passaggio successivo sarà scegliere una Pipeline di compilazione che legga il codice sorgente e lo trasformi in codice eseguibile (ad esempio, Kudu, Azure Pipilines o GitHub Actions). Logicamente la scelta della pipeline dipende dallo stack del linguaggio e dai comandi specifici che possono eseguire (ad esempio la compilazione di codice, la modifica di HTML e JavaScript, l'esecuzione di test e la creazione di pacchetti di componenti).
• Meccanismo di distrubizione:Il meccanismo di distribuzione è l'azione utilizzata per inserire l'applicazione compilata nella directory /home/site/wwwroot della Web App. La directory /wwwroot è un percorso di archiviazione montato condiviso da tutte le istanze della Web App. Quando il meccanismo di distribuzione inserisce l'applicazione in questa directory, le istanze ricevono una notifica per sincronizzare i nuovi file. La Web App supporta meccanismi di continuos deployment o continuos delivery utilizzando pipeline, canali FTP o di WebDeploy.

A questo punto vediamo come è possibile distribuire l'applicazione nella Web App che ho creato con le seguenti caratteristiche:

• Stack di runtime: .NET Core 2.1 (LTS).
• Sistema operativo: Windows.
• Area geografica: Central US.
• SKU e dimensioni: Standard S1.

Continuos Deployment (CI/CD)

L'App Service di Azure consente la distribuzione continua dai repository GitHub, BitBucket, Azure Repos o Local Git eseguendo gli aggiornamenti più recenti. Per utilizzare uno di questi repository basta autorizzare la Web App a connettersi al repository (è sufficiente autorizzare il servizio di controlle del codice sorgente una sola volta).

Azure Repos e Azure Pipelines

• Selezionare Azure Repos come repository del codice sorgente e cliccare su continua.
• Selezionare Azure Pipelines come provider di compilazione e cliccare su continua.
• Configurare la distribuzione selezionando l’organizzazione, il progetto, il repository, il ramo e il framework di sviluppo dell’applicazione Web e cliccare su continua.
• Dopo aver verificato i parametri di configurazione della distribuzione, nella pagina di riepilogo cliccare su Fine.
• Cliccato su Fine partirà la Configurazione della distribuzione.
• Alla fine della Configurazione della distribuzione vedremo la pagina del Centro distribuzione aggiornarsi e arricchirsi con tutti gli strumenti e le informazioni necessari per la gestione della distribuzione appena configurata.

Abbiamo così configurato una distribuzione in cui abbiamo utilizzato Azure Repos come repository e Azure Pipelines come Pipeline, ma il processo di Configurazione della distribuzione ha fatto molto di più di quello che sembra.

Su Azure DevOps, se apriamo il progetto che abbiamo selezionato durante la fase di configurazione della distruzione e nel menu a sinistra selezioniamo il servizio Pipelines, possiamo vedere che il configuratore a creato una pipeline per la compilazione del codice sorgente.

Ma non solo, nel menù di sinistra cliccando su Releases possiamo vedere che il configuratore ha anche creato una release per distribuire il codice compilato nella Web App.

GitHub e GitHub Actions

• Selezionare Azure Repos come repository del codice sorgente e cliccare su continua.
• Avendo già parlato precedentemente di Azure Pipelines, in questo caso selezioniamo GitHub Actions come provider di compilazione e cliccare su continua.
• Configurare la distribuzione selezionando l’organizzazione, il repository, il ramo, lo stack di runtime e la versione con cui è sviluppata l’applicazione Web e cliccare su continua.
• Dopo aver verificato i parametri di configurazione della distribuzione e prima di cliccare su Fine nella pagina di riepilogo, vi voglio far notare che il configuratore ha preparato uno script per la creazione della action su GitHub.
• Cliccato su Fine partirà la Configurazione della distribuzione.
• Alla fine della Configurazione della distribuzione vedremo la pagina del Centro distribuzione aggiornarsi e arricchirsi con tutti gli strumenti e le informazioni necessari per la gestione della distribuzione appena configurata.

Abbiamo così configurato una distribuzione in cui abbiamo utilizzato GitHub come repository e GitHub Actions come Pipeline e anche in questo il processo di Configurazione della distribuzione ha fatto molto di più di quello che sembra, ma non del tutto.

Apriamo il portale di GitHub e selezioniamo il repository che contiene il codice sorgente dell’applicazione.

Possiamo subito notare che il configuratore a creato una cartella .github/workflows con all’interno il file master_serviceappwebtraining.yml che contiene la configurazione del flusso di lavoro dell’azione GitHub.

Nel menu in alto clicchiamo su Actions, sulla sinistra, nell’elenco dei Workflow, selezioniamo l’azione creata dal configuratore “Build and deploy ASP.Net Core app to Azure Web App – serviceappwebtraining” e vedremo che il job è fallito.



Per capire il motivo per cui il job è fallito clicchiamo su job “Aggiunge o aggiorna la configurazione del flusso di lavoro…”  e poi su “build-and-deploy” nel menu a sinistra.

Navigando nel log possiamo vedere che a fallire è stata la build perché nel file yml di flusso non è specificato il nome del progetto nei comandi dotnet build e dotnet publish. Non ci resta far altro che correggere il file yml nella cartella workflows, aggiungendo il nome del progetto “serviceappwebtraining”.


Dopo aver committato la modifica partirà automaticamente un nuovo job che andrà a buon fine e il codice eseguibile verrà distribuito nella Web App.

BitBucket

• Selezionare BitBucket come repository del codice sorgente e cliccare su continua.
• In questo caso non ci verrà chiesto il provider di compilazione perché Kudu è l’unica opzione al momento e verremo indirizzati direttamente allo step di configurazione della distribuzione. Configurare la distribuzione selezionando il team, il repository e il ramo e cliccare su continua.
• Dopo aver verificato i parametri di configurazione della distribuzione, nella pagina di riepilogo cliccare su Fine.
• Cliccato su Fine partirà la Configurazione della distribuzione.
• Alla fine della Configurazione della distribuzione vedremo la pagina del Centro distribuzione aggiornarsi e arricchirsi con tutti gli strumenti e le informazioni necessari per la gestione della distribuzione appena configurata.

Se attendiamo qualche secondo potremmo vedere che Kudu andrà a recuperare il codice sorgente dal repository BitBucket, compilerà il codice sorgente e distribuirà il codice eseguibile nell’App Web. Cliccando nel menu in altro sul pulsante Sfoglia ci verrà aperto il browser con l’url dell’App Web.

Local Git e Azure Pipelines

• Selezionare Local Git come repository del codice sorgente e cliccare su continua.
• Avendo già parlato precedentemente di Azure Pipelines, in questo caso selezioniamo GitHub Actions come provider di compilazione e cliccare su continua.
• Allo step di configurazione possiamo scegliere se utilizzare una nuova organizzazione di Azure DevOps oppure una esistente:
  • Se scegliamo Nuovo, ci verrà richiesto il nome dell’organizzazione, il percorso di localizzazione e il framework di sviluppo dell’applicazione web.
  • Se scegliamo Esistente, ci verrà richiesto l’organizzazione, il progetto e il framework di sviluppo dell’applicazione web.
• Dopo aver cliccato su Continua e aver verificato i parametri di configurazione della distribuzione, nella pagina di riepilogo cliccare su Fine.
• Cliccato su Fine partirà la Configurazione della distribuzione.
• Alla fine della Configurazione della distribuzione vedremo la pagina del Centro distribuzione aggiornarsi e arricchirsi con tutti gli strumenti e le informazioni necessari per la gestione della distribuzione appena configurata.

Abbiamo così configurato una distribuzione in cui, come nel primo punto, abbiamo utilizzato Azure Repos come repository e Azure Pipelines come Pipeline. Come nel primo punto se abbiamo utilizzato un progetto già esistente, il configuratore si sarà incaricato di creare le Pipeline di Build del codice sorgente e di Release del codice eseguibile; ma se abbiamo scelto di creare una nuova organizzazione il configuratore ha anche creato una nuova organizzazione e un nuovo progetto. In questo caso ho scelto la creazione di una nuova organizzazione, quindi il deploy è fallito perché il branch è vuoto. Al primo commit la distribuzione andrà a buon fine.

Conclusioni

In questo 2° articolo su Azure App Service abbiamo visto i 4 casi di continuos deployment di un’applicazione web utilizzando delle Pipeline di CI/CD. Nel prossimo articolo vedremo i casi di manual deployment tramite FTP o WebDeploy.