Visual Studio Team Service continuous delivery di una SPA su Azure
In questo articolo spiegherò come utilizzare Visual Studio Team Service (VSTS) per compilare un progetto ASP .NET Core e Angular.
Innanzitutto, darò per scontato che sia stato creato un progetto ASP .NET Core e Angular e sia stato creato un Service Endpoint per Azure.
Quindi se vengono soddisfatte le pre-condizioni, possiamo accedere a Visual Studio Team Service e creare una nuova Build Definitions di tipo .NET Core.
Agente di Build
L’agente di build di tipo hosted ci fornisce un intero server per la compilazione di diverse tipologie di applicazioni. Il server di build, sia esso hosted o una una macchina configurata ad hoc, ci consente di compilare e rilasciare l’applicazione; in aggiunta abbiamo a disposizione le funzionalità per l’esecuzione di test, pubblicazione di pacchetti Nuget o NPM e una serie di attività volte al rilascio applicativo in ambiente on-premise o cloud.
All’interno della macchina sono presenti diverse versioni di Visual Studio oltre che numerose versioni di Azure SDK, Git, Node.js, NPM, Typescript, Xamarin e Android etc.
L’agente hosted ci viene fornito con un minutaggio limitato il quale viene resettato ogni mese. Nel caso in cui il software presente nell’host non fosse sufficiente è possibile creare un server su Virtual Machine o Dev Test. In questo secondo caso, l’aggiornamento dell’ambiente e la configurazione sarà a carico nostro e non ci sarà alcun vincolo sui tempi di compilazione.
Nel momento in cui sto scrivendo l’articolo, sono presenti tre principali tipologie di Hosted Agent: Hosted, Hosted VS2017, Hosted Linux Preview. Per maggiori dettagli è possibile consultare la pagina della documentazione.
Build definition
La build definition di partenza fornisce alcuni task utilizzati per la compilazione e preceduti dallo step Get Resources che scarica il codice sorgente nel server di build.
Per la compilazione di un progetto .NET Core ci vengono forniti quattro task: Restore, Build, Test, Publish.
Per la compilazione di un progetto Angular dovremmo aggiungerne di nuovi come segue. Le folder del progetto Angular sono state descritte in un articolo precedente.
Update NPM on Build Server
Con il seguente comando andiamo ad aggiornare NPM all’ultima versione. Questo step ci può essere utile per ottimizzare il processo di compilazione e di aggiornare gli strumenti di build.
Working folder: AngularCore/AppEsempio
Command and arguments: i npm
NPM Install with Dev Dependency
Installiamo oltre ai pacchetti utilizzati per la compilazione dell’app, anche i pacchetti per lo sviluppo Angular tra i quali possiamo trovare angular-cli che ci consentirà di compilare il progetto.
Working folder: AngularCore/AppEsempio
Command and arguments: install –dev
Angular-cli Build
Con questo comando consentiamo ad angular-cli di compilare il codice della single page application. Anzichè eseguire ng build utilizziamo un nuovo alias che ci consentirà di aggiungere ulteriori parametri in fase di compilazione.
Nel file package.json di angular era stato specificata la dicitura: “vsts”: “ng build –prod –aot=false” che forza una compilazione per la produzione con l’esclusione del compilatore Ahead-of-time.
Working folder: AngularCore/AppEsempio
Command and arguments: run vsts
Creazione di una WebApp su Azure
Di conseguenza per procedere al rilascio, sarà necessario creare sul portale di Azure una nuova risorsa di tipo WebApp con il Service Plan (piano di servizio) desiderato. Per il rilascio in ambiente di produzione è consigliato un Service plan uguale o superiore al livello Standard.
Quindi la creazione della WebApp dal portale è necessaria per definire le risorse da utilizzare nella fase di rilascio dell’applicazione.
Attraverso VSTS ci agganceremo alle risorse create per aggiornarle rilasciando la nuova versione dell’applicazione.
I dati richiesti per la creazione di una WebApp sono: nome dell’app univoco, sottoscrizione, gruppo di risorse, sistema operativo e service plan. Infine è possibile aggiungere anche una nuova risorsa di monitoraggio come Application Insights che ci consente di monitorare lo stato del sistema e di analizzare l’interazione degli utenti con il sistema.
Release Definitions
Le operazioni effettuate fino a questo momento sono state utili per compilare gli eseguibili e generare i file statici della Single Page Application. Di conseguenza devo rilasciare i sorgenti nell’ambiente di test e successivamente in quello di release.
In questo ultimo capitolo descrivo come si possono rilasciare i sorgenti nella WebApp di Azure; il procedimento può essere effettuato sia per gli slot utilizzati di test che per lo slot di produzione.
Durante la configurazione di una release definition, devo impostare qual’è la corretta build definition sorgente; di conseguenza andremo a recuperare i file per il rilascio dall’ultima versione di build selezionata.
Nell’esempio corrente vado a selezionare la build definition appena descritta che conterrà i file come in figura
Nella release definition sono presenti solamente 2 passaggi:
Deploy ASP .NET Core
Seleziono la sottoscrizione, la WebApp appena creata, e lo zip contenente il sorgente $(System.DefaultWorkingDirectory)/BuildAngularAspNetCore/drop/AngularCore.zip
Deploy Angular
Seleziono la sottoscrizione, la WebApp appena creata, e la cartella contenente il file statici da inserire nella cartella wwwroot: $(System.DefaultWorkingDirectory)/BuildAngularAspNetCore/drop
La folder $(System.DefaultWorkingDirectory) punta ai file generati dalla build definition.
In questo articolo ho mostrato come è possibile configurare lo strumento VSTS per la compilazione dell’applicazione.
In conclusione, definendo uno o più ambienti per il rilascio, sarà possibile portare il codice in produzione.
