![WebApp Slots and WebAPI versioning
Nicolò Carandini [MVP]
n.carandini@outlook.com
@TPCWare](https://image.slidesharecdn.com/webappslotsandwebapiversioning-170704110913/85/Web-app-slots-and-WebAPI-versioning-2-320.jpg)
Web app slots and WebAPI versioning
- 2. WebApp Slots and WebAPI versioning Nicolò Carandini [MVP] [email protected] @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