A how to guide for using Web app slots and WebAPI versioning with Azure

2. WebApp Slots and WebAPI versioning
Nicolò Carandini [MVP]
n.carandini@outlook.com
@TPCWare

3. Argomenti trattati
Oggi parliamo di:
- WebApp slots
- WebAPI versioning
Il contesto d’uso è:
- Azure
- ASP.NET Core
- Visual Studio 2017
…e se rimane tempo, altri scenari di versioning and update

4. WebApp Slots
In generale si usano almeno tre slots:
• Develop
• Staging
• Production
Ma nessuno vieta di usarne altri:
• Test
• Q&A
• …

5. Slot di uso comune
Development
• L’ambiente di sviluppo è quello in cui si pubblica una versione durante lo
sviluppo di una o più funzionalità
Staging
• Per convenzione è l’ambiente in cui si fanno gli ultimi controlli prima di andare
in produzione, quindi è un ambiente che ricrea il più fedelmente possibile le
condizioni d’uso dell’ambiente di produzione.
Production
• Questo ambiente è quello che usano gli utenti quindi qui deve arrivare solo
ciò che funziona, dopo aver passato tutti i test funzionali e di integrazione,
con tutti i requisiti di quality assurance.

6. WebApp Slots in Azure
Per usare gli slot in Azure, occorre utilizzare un piano Standard o Premium

7. Creazione degli slot
Dal portale Azure, selezionare la Web App e aggiungere gli slot:

8. Swapping
Dal portale Azure, selezionare gli slot di sorgente e destinazione:

9. Configurazione degli slot
Per utilizzare i diversi slot occorre definire:
• Le impostazioni di slot che vengono scambiate
• Le impostazioni di slot che non vengono scambiate
• I diversi profili di pubblicazione su Visual Studio e/o gli strumenti di CI/CD

10. Impostazioni che vengono scambiate tra slot
Vi sono impostazioni che devono essere scambiate durante uno swap, perché
sono proprie dell’applicazione che viene spostata da uno slot all’altro:
• Impostazioni generali, quali la versione del framework, 32/64 bit, i socket Web
• Impostazioni app configurate per adattarsi a uno slot
• Stringhe di connessione configurate per adattarsi a uno slot
• Mapping dei gestori
• Impostazioni di monitoraggio e diagnostica
• Contenuto WebJobs

11. Impostazioni che non vengono scambiate tra slot
Vi sono impostazioni che non devono essere modificate durante uno swap,
perché sono proprie di quello specifico slot:
• Endpoint di pubblicazione
• Nomi di dominio personalizzati
• Certificati e associazioni SSL
• Impostazioni di scalabilità
• Utilità di pianificazione WebJobs
• Stringhe di connessione specifiche di uno slot

12. Gestione della connessione al database
Database di sviluppo ≠ Database di produzione !!!
Quello di sviluppo conterrà dati di prova utili ai diversi test di integrazione e
sarà oggetto di modifiche sia strutturali che di contenuto.
Per quanto riguarda lo staging, il discorso si fa più complesso e andrà applicata
la strategia più adatta per il progetto in questione, come l’intera replica del
database di produzione oppure solo di un suo sottoinsieme significativo.

13. Configurazione delle impostazioni di slot
Selezionando il flag di slot setting, l’impostazione non viene scambiata tra slot:

14. Slot App Settings
Le impostazioni dell’app si riferiscono allo slot di default (production). Per
modificare le impostazioni degli altri slot, selezionare prima lo slot:

15. Scambio con anteprima (swap multifase)
Quando si usa l'opzione Scambio con anteprima vengono effettuate le seguenti
operazioni:
• Lo slot di destinazione non viene modificato.
• Vengono applicati gli elementi di configurazione dello slot di destinazione allo slot
di origine.
• Riavvio dei processi di lavoro nello slot di origine usando la nuova configurazione.
• Al completamento dello scambio: lo slot di origine viene spostato nello slot di
destinazione e lo slot di destinazione viene spostato nello slot di origine come in
uno scambio manuale.
• In caso di annullamento dello scambio: gli elementi di configurazione dello slot di
origine vengono riapplicati allo slot di origine.

16. Scambio automatico
Lo scambio automatico semplifica gli scenari nei quali si vuole distribuire
continuamente l'app senza avvio a freddo e senza tempi di inattività.
Quando uno slot di distribuzione viene configurato per lo scambio automatico
in produzione, ogni volta che si esegue il push dell'aggiornamento del codice in
tale slot, il servizio app eseguirà automaticamente lo scambio dell'app in
produzione dopo che è stato eseguito il warm up nello slot di origine.

17. Demo
WebApp slots in Azure

18. WebApp Slots in ASP.NET Core
• ASP.NET Core è già da qualche mese in RTM
• Visual Studio 2017 è in dirittura d’arrivo.
• Le novità sono tantissime e i vantaggi offerti da ASP.NET Core sono tali da
renderlo sicuramente preferibile a molti altri framework di sviluppo di
applicazioni Web e WebAPI, incluso NodeJS.
Per questo motivo è importante vedere cosa cambia nell’uso degli slot per
quanto riguarda le Web App realizzate in ASP.NET Core.

19. Lavorare in ambienti multipli con ASP.NET Core
• ASP.NET Core introduce un miglior supporto per la gestione e il controllo del
comportamento dell’applicazione nei diversi slot di sviluppo, staging e
produzione.
• Valori di ambiente vengono utilizzati per indicare l’ambiente in cui
l’applicazione sta girando, consentendo un’appropriata configurazione della
stessa.

20. Impostare l’ambiente
• Utilizzare una variabile di configurazione del progetto può essere molto
pericoloso, perché è facile dimenticare una impostazione utilizzata per lo
sviluppo che viene poi pubblicata insieme al progetto nell’ambiente di
produzione.
• Per questo motivo ASP.NET Core utilizza valori propri del contesto di
esecuzione:
• In locale, vengono usate le variabili d’ambiente del PC.
• Su Azure, vengono utilizzati gli App Settings.
• Per convenzione, il nome della variabile è ASPNETCORE_ENVIRONMENT.
• Se su Azure la variabile non è definita, il valore d’ambiente è Production.

21. Gestire l’impostazione di ambiente con VS 2017
Per quanto riguarda l’ambiente di sviluppo da Visual Studio è facile definire la
variabile ASPNETCORE_ENVIRONMENT (ed eventuali altre variabili) via GUI, i
cui valori verranno salvati nel file launchSettings.json

22. Gestire l’impostazione di ambiente senza VS 2017
Se non si utilizza Visual Studio, è sempre possibile impostare manualmente la
variabile da Windows, Unix e OSX:

23. Utilizzare la variabile d’ambiente a runtime
• ASP.NET Core offre un servizio IHostingEnvironment che può essere
iniettato nella logica di startup o nei controller.
• Ad esempio, nella classe startup.cs generata dal template di VS:

24. IHostingEnvironment
• Il servizio IHostingEnvironment un’astrazione di base per lavorare con i diversi
ambienti (locale o di pubblicazione)
• Tramite l’istanza di una classe che implementa l’interfaccia di tale servizio, è
possibile conoscere l’ambiente in cui sta girando l’applicazione.
• Se occorre sapere il nome, basta utilizzare la proprietà EnvironmentName.
• Altrimenti è preferibile utilizzare il metodo
IsEnvironment(string environmentName)
che ignora i caratteri in maiuscolo, sia nella variabile di ambiente sia nel
parametro passato al metodo.

25. Environment tag helper
Nelle View è possibile utilizzare sia la tecnica di service injection sia il tag helper
Environment:

26. Demo
ASP.NET Core WebApp Environments

27. WebAPI con ASP.NET Core
• Se prima esistevano due tipi di progetto diversi, uno per le Web App e l’altro
per le WebAPI, con funzionamento simile ma basato su librerie differenti, ora
con ASP.NET Core abbiamo tutto nello stesso progetto.
• La gestione del Routing viene fatta come prima, a livello di Controller:

28. WebAPI Netiquette
Poiché una WebAPI altro non è che un servizio RESTful che viene esposto
all’esterno per essere utilizzato da altri, è molto importante:
• Definire una strategia di versioning
• Documentare in moto puntuale l’API (Application Program Interface)

29. WebAPI Versioning
Poiché l’API esposta da un servizio è inevitabilmente soggetta a cambiamento
nel corso del tempo, una corretta strategia di versioning consente tali modifiche
senza "rompere" il funzionamento di altre applicazioni che utilizzano tale
servizio.
Un metodo molto semplice è quello di utilizzare nelle classi Controller una
dichiarazione di Route che contenga esplicitamente il numero di versione:

30. Documentazione dell’API
Un ottimo sistema di documentazione è Swagger, che consente di descrivere
l’API di un servizio REST con un linguaggio JSON-like.
Per i progetti ASP.NET Core è disponibile sotto forma di pacchetto NuGet la
libreria Swashbuckle.AspNetCore, che è in grado di produrre tale
documentazione in modo automatico a partire dal codice contenuto nelle varie
classi Controller.
Le informazioni d’uso si trovano su GitHub all’indirizzo:
https://github.com/domaindrivendev/Swashbuckle.AspNetCore

31. Demo
ASP.NET Core WebAPI Versioning

32. Question time

33. Thanks to our Sponsors

34. Feedback Form
Compilate il feedback form!!
Aiutateci a migliorare la qualità degli eventi!!!
Track A
http://svy.mk/2l9THNc
Track B
http://svy.mk/2leDPWR