Author Archives: Davide Benvegnù
A proposito della Build di Xamarin con gli Hosted Agent di VSTS
Venerdì scorso (22/04/2016) durante un’evento organizzato da DotNetToscana ho avuto modo di parlare, tra le altre cose, della build di applicazioni sviluppate con Xamarin utilizzando gli Hosted Agent di Visual Studio Team Services.
Per poter far funzionare il tutto, nella build definition ho dovuto inserire due task relativi alla Xamarin License: uno che attivava la licenza ed un altro che, dopo la compilazione, la disattivava.
E proprio riguardo a questi due task, c’è una piccola grande novità: ora non sono più necessari.
Con il deploy che hanno fatto qualche giorno fa, infatti, gli Hosted Build Agent hanno già una loro licenza interna che viene attivata automaticamente nel momento in cui devono compilare i progetti Xamarin.
Riepilogando, se avete o dovete fare delle build definition per Xamarin (ed usate gli Hosted Agent) ora non dovete più aggiungere i task di attivazione e disattivazione della licenza.
Buona build a tutti 
A proposito della Build di Xamarin con gli Hosted Agent di VSTS
Venerdì scorso (22/04/2016) durante un’evento organizzato da DotNetToscana ho avuto modo di parlare, tra le altre cose, della build di applicazioni sviluppate con Xamarin utilizzando gli Hosted Agent di Visual Studio Team Services.
Per poter far funzionare il tutto, nella build definition ho dovuto inserire due task relativi alla Xamarin License: uno che attivava la licenza ed un altro che, dopo la compilazione, la disattivava.
E proprio riguardo a questi due task, c’è una piccola grande novità: ora non sono più necessari.
Con il deploy che hanno fatto qualche giorno fa, infatti, gli Hosted Build Agent hanno già una loro licenza interna che viene attivata automaticamente nel momento in cui devono compilare i progetti Xamarin.
Riepilogando, se avete o dovete fare delle build definition per Xamarin (ed usate gli Hosted Agent) ora non dovete più aggiungere i task di attivazione e disattivazione della licenza.
Buona build a tutti
Disponibili BugGuardian.MVC e BugGuardian.WebForms
Oggi sono veramente felice di poter annunciare il rilascio di 2 moduli addizionali per BugGuardian.
Per chi non lo conoscesse, BugGuardian è una libreria che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Team Services o su un Team Foundation Server 2015 on-premises nel caso in cui l’applicazione sollevi un’eccezione non gestita (Unhandled Exception).
Per supportare nel modo migliore l’integrazione di questa libreria con i progetti web, da oggi sono disponibili BugGuardian.MVC and BugGuardian.WebForms.
BugGuardian.MVC (GitHub, NuGet) è un estensione di BugGuardian scritta specificamente per supportare ed integrarsi con le applicazioni Asp.net MVC.
Aggiunge degli Action Filter alle tue applicazioni in modo da poter intercettare automaticamente tutte le eccezioni non gestite.
BugGuardian.WebForms (GitHub, NuGet), invece, è un modulo aggiuntivo per BugGuardian scritto specificamente per supportare le applicazioni Asp.net WebForms.
Queste due nuove librerie sono entrambe basate sulla nuova versione 1.3.0 di BugGuardian (anch’essa rilasciata da pochissimo) e supportano progetti che utilizzano il .Net Framework v4.0 e superiori.
Com’è per BugGuardian, queste due librerie aggiuntive sono Open Source; guardate pure il codice su GitHub.
Se doveste avere dubbi o problemi durante l’utilizzo di queste nuove librerie, fatemelo sapere attraverso le rispettive Issues page di GitHub e cerchero di fixare il problema prima possibile!
Di nuovo, Voglio ringraziare il mio amico e “collega” MVP Marco Minerva (@marcominerva, GitHub) per il supporto ed i suggerimenti.
Disponibili BugGuardian.MVC e BugGuardian.WebForms
Oggi sono veramente felice di poter annunciare il rilascio di 2 moduli addizionali per BugGuardian.
Per chi non lo conoscesse, BugGuardian è una libreria che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Team Services o su un Team Foundation Server 2015 on-premises nel caso in cui l’applicazione sollevi un’eccezione non gestita (Unhandled Exception).
Per supportare nel modo migliore l’integrazione di questa libreria con i progetti web, da oggi sono disponibili BugGuardian.MVC and BugGuardian.WebForms.
BugGuardian.MVC (GitHub, NuGet) è un estensione di BugGuardian scritta specificamente per supportare ed integrarsi con le applicazioni Asp.net MVC.
Aggiunge degli Action Filter alle tue applicazioni in modo da poter intercettare automaticamente tutte le eccezioni non gestite.
BugGuardian.WebForms (GitHub, NuGet), invece, è un modulo aggiuntivo per BugGuardian scritto specificamente per supportare le applicazioni Asp.net WebForms.
Queste due nuove librerie sono entrambe basate sulla nuova versione 1.3.0 di BugGuardian (anch’essa rilasciata da pochissimo) e supportano progetti che utilizzano il .Net Framework v4.0 e superiori.
Com’è per BugGuardian, queste due librerie aggiuntive sono Open Source; guardate pure il codice su GitHub.
Se doveste avere dubbi o problemi durante l’utilizzo di queste nuove librerie, fatemelo sapere attraverso le rispettive Issues page di GitHub e cerchero di fixare il problema prima possibile!
Di nuovo, Voglio ringraziare il mio amico e “collega” MVP Marco Minerva (@marcominerva, GitHub) per il supporto ed i suggerimenti.
Benvenuto BugGuardian
Qualcuno avrà probabilmente notato che negli ultimi mesi ho scritto solo qualche post qui sul blog. Questo per due motivi principali
Il primo è che, come alcuni già sanno, qualche mese fa mi sono trasferito in un altro paese, piuttosto lontano, con una cultura ed una lingua piuttosto differenti, dove ho iniziato una nuova avventura. Questo ha inevitabilmente preso molto del mio già risicato tempo libero.
Il secondo motivo per cui non sono stato molto attivo qui, che è anche la ragione di questo post, è che ho lavorato ad un nuovo progetto che ho rilasciato oggi: BugGuardian.
Cos’è BugGuardian
BugGuardian è una libreria Open Source, scritta in C# Shared Project, che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Online o su un Team Foundation Server 2015 on-premises nel caso in cui l’applicazione sollevi un’eccezione non gestita (Unhandled Exception).
Può essere ovviamente usata anche con delle invocazioni manuali nei blocchi di try/catch per tenere traccia delle eccezioni gestite.
Può essere ovviamente usata anche con delle invocazioni manuali nei blocchi di try/catch per tenere traccia delle eccezioni gestite.
Questa libreria supporta applicazioni scritte con il .Net Framework v4.0 e superiori e può essere usata in moltissimi tipi di progetto, tra cui:
- Asp.net
- Asp.net MVC
- WPF
- Windows 8 / 8.1 Apps
- Windows Phone 8 / 8.1 Apps
- Universal App
- Universal Windows Platform Apps (Windows 10)
- ecc
Come ho detto, si tratta di un OSS quindi potete trovare tutti i sorgenti pubblicati su GitHub.
Per poterla installare ed usare senza necessariamente doverla compilare manualmente, ho pubblicato il pacchetto su NuGet. È sufficiente cercare BugGuardian nella Package Manager GUI o eseguire il seguente comando Package Manager Console:
Install-Package DBTek.BugGuardian
Install-Package DBTek.BugGuardian
Utilizzo, supporto e Feedback
Per trovare linee guida ed esempi sull’utilizzo della libreria consultate la documentazione del progetto. Inoltre nella cartella TestApps dei sorgenti ci sono alcuni esempi di utilizzo con i tipi di applicazione più comuni.
Ad ogni modo, solo per fare un esempio di quanto sia semplice utilizzarla, questo è il codice di cui avrete bisogno per gestire un’eccezione e creare il relativo Bug su VSO / TFS:
using (var creator = new DBTek.BugGuardian.Creator())
{
creator.AddBug(myException);
}
Se avete dei dubbi o dei problemi durante l’utilizzo di questa libreria, fatemelo sapere attraverso la Issues page di GitHub e cerrchero di fixare il problema prima possibile!
Attendo i vostri feedback
Voglio ringraziare il mio amico e “collega” Marco Minerva (@marcominerva) per il supporto, la pazienza e la Code Review.
Benvenuto BugGuardian
Qualcuno avrà probabilmente notato che negli ultimi mesi ho scritto solo qualche post qui sul blog. Questo per due motivi principali
Il primo è che, come alcuni già sanno, qualche mese fa mi sono trasferito in un altro paese, piuttosto lontano, con una cultura ed una lingua piuttosto differenti, dove ho iniziato una nuova avventura. Questo ha inevitabilmente preso molto del mio già risicato tempo libero.
Il secondo motivo per cui non sono stato molto attivo qui, che è anche la ragione di questo post, è che ho lavorato ad un nuovo progetto che ho rilasciato oggi: BugGuardian.
Cos’è BugGuardian
BugGuardian è una libreria Open Source, scritta in C# Shared Project, che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Online o su un Team Foundation Server 2015 on-premises nel caso in cui l’applicazione sollevi un’eccezione non gestita (Unhandled Exception).
Può essere ovviamente usata anche con delle invocazioni manuali nei blocchi di try/catch per tenere traccia delle eccezioni gestite.
Può essere ovviamente usata anche con delle invocazioni manuali nei blocchi di try/catch per tenere traccia delle eccezioni gestite.
Questa libreria supporta applicazioni scritte con il .Net Framework v4.0 e superiori e può essere usata in moltissimi tipi di progetto, tra cui:
- Asp.net
- Asp.net MVC
- WPF
- Windows 8 / 8.1 Apps
- Windows Phone 8 / 8.1 Apps
- Universal App
- Universal Windows Platform Apps (Windows 10)
- ecc
Come ho detto, si tratta di un OSS quindi potete trovare tutti i sorgenti pubblicati su GitHub.
Per poterla installare ed usare senza necessariamente doverla compilare manualmente, ho pubblicato il pacchetto su NuGet. È sufficiente cercare BugGuardian nella Package Manager GUI o eseguire il seguente comando Package Manager Console:
Install-Package DBTek.BugGuardian
Install-Package DBTek.BugGuardian
Utilizzo, supporto e Feedback
Per trovare linee guida ed esempi sull’utilizzo della libreria consultate la documentazione del progetto. Inoltre nella cartella TestApps dei sorgenti ci sono alcuni esempi di utilizzo con i tipi di applicazione più comuni.
Ad ogni modo, solo per fare un esempio di quanto sia semplice utilizzarla, questo è il codice di cui avrete bisogno per gestire un’eccezione e creare il relativo Bug su VSO / TFS:
using (var creator = new DBTek.BugGuardian.Creator())
{
creator.AddBug(myException);
}
Se avete dei dubbi o dei problemi durante l’utilizzo di questa libreria, fatemelo sapere attraverso la Issues page di GitHub e cerrchero di fixare il problema prima possibile!
Attendo i vostri feedback
Voglio ringraziare il mio amico e “collega” Marco Minerva (@marcominerva) per il supporto, la pazienza e la Code Review.
Deployare una Web App su Azure con la nuova Build di Visual Studio Online
In questo post vedremo come fare, iniziando da 0, a deployare una nostra soluzione su una Web App di Azure utilizzando la nuova Build di Visual Studio Online.
Per farlo, useremo esclusivamente il portale web di VSO.
Collegare Azure a VSO
Innanzitutto bisogna “far sapere” a Visual Studio Online che abbiamo un account Azure che vogliamo utilizzare come endpoint di deploy per la nostra soluzione.
Per farlo, dobbiamo andare nella parte dei setting del progetto (cliccando sull’apposito bottone presente in alto a destra, dopo essere entrati nella pagina del progetto), cliccare sulla tab “Services“, poi su “Add new Service Connection” ed infine su “Azure“.
A questo punto si aprirà un popup dove dovremo inserire l’ID della sottoscrizione Azure che contiene o conterrà la web app da pubblicare, un nome (anche se il campo si chiama “Subscription Name“, non è necessario usare il nome della sottoscrizione, si tratta di un campo di testo libero che ci servirà per identificare la sottoscrizione nel caso ne collegassimo più di una a VSO) e le modalità di autenticazione.
È possibile utilizzare sia un certificato (reperibile tramite il portale di Azure) sia direttamente le credenziali.
Fatto questo, la nostra subscription di Azure e il nostro account Visual Studio Online saranno collegati (almeno su questo team project).
Creare la build definition
Ora che abbiamo impostato la connessione tra VSO ed Azure, spostiamoci nella sezione Build del progetto e creiamo una nuova build definition di tipo deployment.
Siccome vogliamo deployare su Azure, nella sezione “Deployment” scegliere “Azure Website” come indicato nell’immagine.
Verrà create una nuova build definition con alcuni step da configurare.
Vediamo passo passo come procedere.
Il primo step rappresenta il vero e proprio processo di Build. È completamente configurabile, ma la cosa più importante è quella di definire il file di soluzione che dovrà essere utilizzato come source della build. Va selezionato nella casella indicata dalla freccia rossa.
Nel secondo step vanno inseriti i criteri di esecuzione post-build degli Unit Test. Se non abbiamo degli unit test (male…) oppure non vogliamo eseguirli (male anche questo ) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.
) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.Il terzo step è quello che ci interessa di più in quanto è quello che si occupa di fare il deploy del risultato della Build verso la nostra web app su Azure.
Qui troviamo un menu a discesa in cui, se l’associazione della sottoscrizione Azure è andata a buon fine, troviamo le nostre sottoscrizioni collegate a VSO e possiamo scegliere quella che faà da target per il deploy.
Nella casella successiva, denominata “Web App Name” dobbiamo inserire manualmente il nome della Web App di destinazione. Come vedete in realtà si tratta anche in questo caso di una Combo Box, ma al momento attuale le Web App già esistenti non vengono caricate automaticamente (non dimentichiamo che questa nuova build è ancora in preview).
Ecco quindi alcuni consigli e note:
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione e che non esiste nella region selezioanta, verrà creata su Azure nella region selezionata
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione ma che esiste già in quella region, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione ma che è in una region diversa, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione e che si trova nella region selezionata, il deploy utilizzerà quella web app e la aggiornerà
Quindi attenzione a quello che scriviamo
I due step rimanenti danno la possibilità di indicizzare e pubblicare i simboli della nostra applicazione (consigliato per poter avere informazioni aggiuntive in caso di eccezioni non gestite) e di pubblicare gli artifact risultati dalla build.
Quando abbiamo impostato tutti i parametri, possiamo salvare la nostra build definition assegnandole un nome.
Possiamo anche modificare i vari parametri di default navigando nelle varie tab per personalizzare la build secondo le nostre esigenze.
Deployamo!
Una volta completate le personalizzazioni, è il momento di lanciare la compilazione e di verificare che il processo di deploy vada a buon fine.
Per lanciare la build, utilizziamo il bottone “Queue build” presente nella toolbar della build definition oppure nel menu contestuale della build stessa.
Quando clicchiamo su quel bottone, il sistema accoderà una build su un agente di compilazione presente sui nostri server oppure in un datacente Microsoft (nel caso in cui abbiamo scelgto di utilizzare la build “hosted”)
In ogni caso il progesso sarà visibile nella console real time presente sul web.
Prima verranno eseguiti i task di build e di test:
Poi, al successo di entrambi, il deploy verso azure:
Quando tutto sarà finito, avremo la nostra applicazione funzionante e deployata su Azure. Facile!
Deployare una Web App su Azure con la nuova Build di Visual Studio Online
In questo post vedremo come fare, iniziando da 0, a deployare una nostra soluzione su una Web App di Azure utilizzando la nuova Build di Visual Studio Online.
Per farlo, useremo esclusivamente il portale web di VSO.
Collegare Azure a VSO
Innanzitutto bisogna “far sapere” a Visual Studio Online che abbiamo un account Azure che vogliamo utilizzare come endpoint di deploy per la nostra soluzione.
Per farlo, dobbiamo andare nella parte dei setting del progetto (cliccando sull’apposito bottone presente in alto a destra, dopo essere entrati nella pagina del progetto), cliccare sulla tab “Services“, poi su “Add new Service Connection” ed infine su “Azure“.
A questo punto si aprirà un popup dove dovremo inserire l’ID della sottoscrizione Azure che contiene o conterrà la web app da pubblicare, un nome (anche se il campo si chiama “Subscription Name“, non è necessario usare il nome della sottoscrizione, si tratta di un campo di testo libero che ci servirà per identificare la sottoscrizione nel caso ne collegassimo più di una a VSO) e le modalità di autenticazione.
È possibile utilizzare sia un certificato (reperibile tramite il portale di Azure) sia direttamente le credenziali.
Fatto questo, la nostra subscription di Azure e il nostro account Visual Studio Online saranno collegati (almeno su questo team project).
Creare la build definition
Ora che abbiamo impostato la connessione tra VSO ed Azure, spostiamoci nella sezione Build del progetto e creiamo una nuova build definition di tipo deployment.
Siccome vogliamo deployare su Azure, nella sezione “Deployment” scegliere “Azure Website” come indicato nell’immagine.
Verrà create una nuova build definition con alcuni step da configurare.
Vediamo passo passo come procedere.
Il primo step rappresenta il vero e proprio processo di Build. È completamente configurabile, ma la cosa più importante è quella di definire il file di soluzione che dovrà essere utilizzato come source della build. Va selezionato nella casella indicata dalla freccia rossa.
Nel secondo step vanno inseriti i criteri di esecuzione post-build degli Unit Test. Se non abbiamo degli unit test (male…) oppure non vogliamo eseguirli (male anche questo ) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.
) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.Il terzo step è quello che ci interessa di più in quanto è quello che si occupa di fare il deploy del risultato della Build verso la nostra web app su Azure.
Qui troviamo un menu a discesa in cui, se l’associazione della sottoscrizione Azure è andata a buon fine, troviamo le nostre sottoscrizioni collegate a VSO e possiamo scegliere quella che faà da target per il deploy.
Nella casella successiva, denominata “Web App Name” dobbiamo inserire manualmente il nome della Web App di destinazione. Come vedete in realtà si tratta anche in questo caso di una Combo Box, ma al momento attuale le Web App già esistenti non vengono caricate automaticamente (non dimentichiamo che questa nuova build è ancora in preview).
Ecco quindi alcuni consigli e note:
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione e che non esiste nella region selezioanta, verrà creata su Azure nella region selezionata
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione ma che esiste già in quella region, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione ma che è in una region diversa, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione e che si trova nella region selezionata, il deploy utilizzerà quella web app e la aggiornerà
Quindi attenzione a quello che scriviamo
I due step rimanenti danno la possibilità di indicizzare e pubblicare i simboli della nostra applicazione (consigliato per poter avere informazioni aggiuntive in caso di eccezioni non gestite) e di pubblicare gli artifact risultati dalla build.
Quando abbiamo impostato tutti i parametri, possiamo salvare la nostra build definition assegnandole un nome.
Possiamo anche modificare i vari parametri di default navigando nelle varie tab per personalizzare la build secondo le nostre esigenze.
Deployamo!
Una volta completate le personalizzazioni, è il momento di lanciare la compilazione e di verificare che il processo di deploy vada a buon fine.
Per lanciare la build, utilizziamo il bottone “Queue build” presente nella toolbar della build definition oppure nel menu contestuale della build stessa.
Quando clicchiamo su quel bottone, il sistema accoderà una build su un agente di compilazione presente sui nostri server oppure in un datacente Microsoft (nel caso in cui abbiamo scelgto di utilizzare la build “hosted”)
In ogni caso il progesso sarà visibile nella console real time presente sul web.
Prima verranno eseguiti i task di build e di test:
Poi, al successo di entrambi, il deploy verso azure:
Quando tutto sarà finito, avremo la nostra applicazione funzionante e deployata su Azure. Facile!
Cloud Load Test con Visual Studio Online – parte 2: Visual Studio
Questo articolo è il secondo di una serie di 3 in cui parlo del Cloud Load Testing con Visual Studio Online.
Nella prima parte abbiamo visto come eseguire dei semplici test di carico usando solamente il portale di VSO.
In questo articolo invece vedremo un soluzione più complessa (ma più completa), l’integrazione tra Visual Studio e Visual Studio Online.
Remainder
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante ricordare alcuni aspetti:
- Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
- L’applicazione da testare deve essere esposta sul web (visto che i test agent sono nel cloud e devono poter raggiungere l’applicazione)
- Gratuitamente si possono utilizzare fino a 20.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuti con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.
Inoltre, la funzionalità di Load test è disponibile solamente su Visual Studio Ultimate/Enterprise.
Fatte queste precisazioni, vediamo come si possono creare ed eseguire i test di carico con Visual Studio e Visual Studio Online.
Introduzione
Facendo un Load test con Visual Studio, avremo un sacco di impostazioni che potremo configurare. Si tratta quindi della soluzione più personalizzabile e configurabile per eseguire questo tipo di test.
Inoltre, dopo l’esecuzione avremo a disposizione molte informazioni, dati e grafici che ci permetterranno di capire come la nostra applicazione si comporta in uno scenario di carico.
Ultimo ma non per importanza, utilizzando VS possiamo fare un test multi step (multi pagina), anche con pagine sottoposte ad autenticazione, e possiamo registrare tutti i passaggi che vogliamo fare nell’applicazione allo stesso modo di come li farebbe l’utente (quindi non è richiesta configurazione manuale!).
Iniziamo
Prima di tutto dobbiamo creare un test project in Visual Studio. Il project template da usare è “Web Performance and Load Test Project”.
Quando clicchiamo sul bottone “Ok”, VS crea per noi una soluzione (come sempre) con all’iterno un progetto “WebTest1.webtest”. Non si tratta di un progetto di “Cloud Test”, bensì di un progetto “Web Performance”. Avremo bisogno di questo progetto per “istruire” il load test su cosa e come testare.
In alto a sinistra della schermata c’è un piccolo bottone con un grosso punto rosso: è il bottone che ci permette di resgistrare tutti gli step che faremo nella nostra applicazione.
Se clicchiamo su questo bottone, verrà aperto il browser (tipicamente IE) che avrà un piccolo pannello sulla sinistra. Si tratta del pannello che “fa il lavoro per noi”; è generato dal plugin “Web Test Recorder helper” che VS installa sulla nostra macchina.
Come nota a margine, ricordate di verificare che quel plugin sia abilitato sul browser altrimenti non verrà visualizzato nulla.
Ok, ora che la registrazione è attiva possiamo visitare ed usare l’applicazione che vogliamo testare esattamente come farebbe un normale utente. Possiamo anche eseguire azioni particolari se vogliamo testare qualche funzionalità o pagina specifica.
Per far iniziare la registrazione è sufficiente scrivere l’indirizzo dell’applicazione nella barra del browser ed iniziare ad usarla: il web recorder plugin farà tutto il resto.
Quando abbiamo finito, abbiamo cioè effettuato tutti gli step e le navigazioni che vogliamo testare, basta clicare sul bottone “Stop”. Abbiamo anche la possibilità di mettere in pausa la registrazione se magari non vogliamo registrare qualche step.
Mentre navighiamo la nostra applicazione, un sacco di “roba” viene aggiunta nel pannello di registrazione. Si tratta di tutte le richieste che la nostra applicazione fa.
Se ne selezioniamo una e clicchiamo sul bottone “comment” possiamo aggiungere un commento alla stessa che sarà possibile recuperare in un secondo momento.
Quando clicchiamo sul bottone “Stop”, succede “la magia”. Dapprima Visual Studio prende tutte le richieste e le informazioni dal web recorder plugin, le elabora e le inserisce nella finestra del webtest. Poi cerca di identificare se ci sono dei “parametri dinamici” nel nostro test.
I dynamic parameters sono tutti quei valori che possono cambiare se le richieste vengono fatte in momenti temporali differenti: user token, ricerche, autenticazioni, ecc. Se VS ne rileva qualcuno ci mostrerà una finestra in cui potremo decidere come e se utilizzarli. Possiamo selezionare di utilizzare per ogni iterazione di test esattamente quelli che sono stati registrati oppure se associare quei parametri ad una sorta di dizionario (che andremo a creare) da cui VS sceglierà di volta in volta valori differenti.
Un altro aspetto interessante che possiamo personalizzare riguarda i “Request details”. In questa finestra possiamo decidere se inserire dei “think time” tra le richieste (sostanzialmente dei ritardi) e, più importante, qual’è per noi il tempo “target” per le response. Se durante il test quella specifica richiesta avrà una response in un tempo maggiore di quello impostato come soglia, VS considererà il test come fallito.
Ora che abbiamo il webtest con tutti gli step ed i parametri impostati, possiamo finalmente aggiungere il progetto di Load Test alla nostra solution.
Il progetto di Load Test
Per aggiungere il test di carico ad un web performance test è sufficiente cliccare con il testo destro del mouse sul nome del progetto, scegliere “Add” e poi “Load test”.
Quest’azione farà comparire il “Load test wizard” che ci guiderà nel setup del test di carico.
Nel primo step dobbiamo scegliere se e come gestire i “think times” (i ritardi tra le request): possiamo usare gli stessi think time acquisiti durante la registrazione (attenzione che se mentre registravamo, tra un click e l’altro abbiamo fatto una pausa di ad esempio 5 minuti, durante il test quei 5 minuti saranno settati come delay tra quelle due richieste), possiamo scegliere “normal distribution” (che fa una sorta di media tra i tempi di delay registrati) oppure proprio di non usarne. Possiamo anche inserire un tempo di attesa tra iterazioni diverse dello stesso test.
Nel secondo step dobbiamo decidere quanto carico vogliamo generare verso la nostra applicazione e le modalità di generazione.
Possiamo selezionare di avere un carico costante (il test inizierà cioè con N utenti e continuerà con lo stesso numero di utenti fino alla fine) o di effetturare un test con “step load”.
Nell’immagine, ad esempio, ho deciso di utilizzare lo step load e di iniziare il test con 10 utenti aggiungendo ulteriori 10 utenti ogni 10 secondi, fino al raggiungimento di un massimo di 200 utenti.
Lo step load può essere molto interessante in quanto possiamo scoprire come (e se) la nostra applicazione scala in base all’incremento del carico applicativo.
Nello step successivo dobbiamo istruire il test di carico sul “cosa” fare. Per questa ragione inseriremo in questa schermata il web performance test che abbiamo creato precedentemente.
Cliccare su “Add”, selezionare il performance test che vogliamo, cliccare su “Ok” ed il test sarà aggiunto nella finestra “test mix”. Si chiama “Test Mix” perchè è possibile aggiungere quanti test vogliamo e se ne mettiamo più di uno possiamo definire la distribuzione percentuale di ognuno. In questo esempio abbiamo un solo test quindi la distribuzione sarà del 100%.
Possiamo anche decidere, negli step successivi, se e come utilizzare diversi tipi di connettività verso la nostra applicazione (attenzione: nel momento in cui scrivo VSO supporta solamente reti di tipo “LAN”) e che tipo di browser engine vogliamo che siano utilizzati dai test agent per effettuare le richieste.
Come potete vedere nell’immagine, possiamo scegliere da un elenco di molti browser ed anche in questo caso possiamo definire la distribuzione percentuale.
Nell’ultimo step possiamo personalizzare la durata dell’esecuzione del test.
Possiamo scegliere tra un tempo fisso oppure un numero di iterazioni di test. Se selezioniamo un tempo fisso (nel mio esempio 2 minuti), possiamo anche impostare un “Warm-up time” (10 secondi nell’esempio). Durante questo tempo verranno inviate alcune richieste all’applicazione per “risvegliarla” e non saranno collezionati dati. Questo comportamento è estremamente utile se dobbiamo testare applicazioni che necessitano di un cold start (come ad esempio webapp hostate su IIS che magari non sono state usate per un periodo di tempo e per le quali quindi IIS ha “disattivato” l’AppPool) per non avere dei falsi positivi nel risultato del test.
Cliccando su “Finish”, Visual Studio genererà il progetto di load test e lo salverà nella nostra soluzione.
Esecuzione del test
Ora che abbiamo tutto pronto possiamo eseguire il test. Ma prima, ancora un piccola impostazione. Noi vogliamo, infatti, che il test di carico sia eseguito attraverso la funzionalità Visual Studio Online Cloud Load Test ma nessuno l’ha detto al nostro Load Test project locale.
Per farlo bisogna aprire (doppo clic) il file “Local.testsettings” e cambiare il puntamento di “Test run location” su Visual Studio Online.
È da notare comunque che se abbiamo effettuato il login in Visual Studio con un account che ha una sottoscrizione a VSO questo step non sarà necessario in quanto VS seleziona direttamente questo valore per noi.
Ok, iniziamo il test cliccando sul bottone di start in alto a sinistra.
Ma cosa succede quando facciamo partire il test?
Visual Studio si connette a Visual Studio Online ed accoda il test. VSO poi crea on demand un lab virtual di test da qualche parte in un datacenter di Azure e configura i test agent sulle VM con i parametri settati.
Non appena il lab è pronto e configurato, il test parte. Se abbiamo configurato un periodo di warm up esso inizierà e potete vedere che non vengono collezionati dati.
Poi, finito il warm up, gli agenti iniziano a generare il traffico verso le pagine della nostra applicazione (così come utilizzate nella nostra registrazione) ed i risultati sono mandati al nostro Visual Studio quasi in tempo reale in modo da poter avere una preview del risultato finale del test.
Aspettiamo la fine del test per avere un resultset completo.
Risultati
Quando il test giunge al termine, verranno visualizzati tutti i risultati e le performance raggiunte. Le informazioni disponibili sono veramente moltissime.
Abbiamo i tempi di risposta medi, con anche il minimo ed il massimo, assieme ai tempi di test medi, i tempi di pagina medi ed il carico utente.
Possiamo vedere dal grafico e dalle info visualizzate che il numero di utenti virtuali è cresciuto nel tempo da 10 a 120 (avevo impostato un max di 200 ma non ha avuto tempo di raggiungere il massimo in quanto il test era limitato a soli 2 minuti con incrementi ogni 10 secondi) e come l’applicazione ha scalato al crescere del carico.
Anche nella sezione “Throughput” possiamo vedere molte informazioni utili.
In questo esempio non abbiamo avuto errori o parametri fuori soglia, ma se ci fossero stati avremmo visto un report degli stessi con le cause ed i messaggi di errore.
Questi sono però solo una piccola parte dei dati che abbiamo a disposizione. Se infatti clicchiamo sul link “download report” in alto, Visual Studio scaricherà l’intero resulset da Visual Studio Online rendendo disponibile, in questo modo, un report con una miriade di dati e grafici su ogni aspetto del test che ci aiuteranno a capire meglio come la nostra applicazione si comporta in uno scenario di carico.
Conclusioni
Questo tipo di Load test è il più completo che possiamo fare. Come potete vedere ci restituisce tantissime informazioni, metriche e grafici che ci permettono di analizzare il comportamento della nostra applicazione.
Inoltre, il setup di questi test è abbastanza semplice ma soprattutto è completamente personalizzabile ed in un poco tempo possiamo ottenere un gran numero di dati da poter consultare.
Il prossimo ed ultimo articolo di questa serie sarà sull’utilizzo delle Load Test APIs. Stay tuned!
Cloud Load Test con Visual Studio Online – parte 2: Visual Studio
Questo articolo è il secondo di una serie di 3 in cui parlo del Cloud Load Testing con Visual Studio Online.
Nella prima parte abbiamo visto come eseguire dei semplici test di carico usando solamente il portale di VSO.
In questo articolo invece vedremo un soluzione più complessa (ma più completa), l’integrazione tra Visual Studio e Visual Studio Online.
Remainder
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante ricordare alcuni aspetti:
- Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
- L’applicazione da testare deve essere esposta sul web (visto che i test agent sono nel cloud e devono poter raggiungere l’applicazione)
- Gratuitamente si possono utilizzare fino a 20.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuti con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.
Inoltre, la funzionalità di Load test è disponibile solamente su Visual Studio Ultimate/Enterprise.
Fatte queste precisazioni, vediamo come si possono creare ed eseguire i test di carico con Visual Studio e Visual Studio Online.
Introduzione
Facendo un Load test con Visual Studio, avremo un sacco di impostazioni che potremo configurare. Si tratta quindi della soluzione più personalizzabile e configurabile per eseguire questo tipo di test.
Inoltre, dopo l’esecuzione avremo a disposizione molte informazioni, dati e grafici che ci permetterranno di capire come la nostra applicazione si comporta in uno scenario di carico.
Ultimo ma non per importanza, utilizzando VS possiamo fare un test multi step (multi pagina), anche con pagine sottoposte ad autenticazione, e possiamo registrare tutti i passaggi che vogliamo fare nell’applicazione allo stesso modo di come li farebbe l’utente (quindi non è richiesta configurazione manuale!).
Iniziamo
Prima di tutto dobbiamo creare un test project in Visual Studio. Il project template da usare è “Web Performance and Load Test Project”.
Quando clicchiamo sul bottone “Ok”, VS crea per noi una soluzione (come sempre) con all’iterno un progetto “WebTest1.webtest”. Non si tratta di un progetto di “Cloud Test”, bensì di un progetto “Web Performance”. Avremo bisogno di questo progetto per “istruire” il load test su cosa e come testare.
In alto a sinistra della schermata c’è un piccolo bottone con un grosso punto rosso: è il bottone che ci permette di resgistrare tutti gli step che faremo nella nostra applicazione.
Se clicchiamo su questo bottone, verrà aperto il browser (tipicamente IE) che avrà un piccolo pannello sulla sinistra. Si tratta del pannello che “fa il lavoro per noi”; è generato dal plugin “Web Test Recorder helper” che VS installa sulla nostra macchina.
Come nota a margine, ricordate di verificare che quel plugin sia abilitato sul browser altrimenti non verrà visualizzato nulla.
Ok, ora che la registrazione è attiva possiamo visitare ed usare l’applicazione che vogliamo testare esattamente come farebbe un normale utente. Possiamo anche eseguire azioni particolari se vogliamo testare qualche funzionalità o pagina specifica.
Per far iniziare la registrazione è sufficiente scrivere l’indirizzo dell’applicazione nella barra del browser ed iniziare ad usarla: il web recorder plugin farà tutto il resto.
Quando abbiamo finito, abbiamo cioè effettuato tutti gli step e le navigazioni che vogliamo testare, basta clicare sul bottone “Stop”. Abbiamo anche la possibilità di mettere in pausa la registrazione se magari non vogliamo registrare qualche step.
Mentre navighiamo la nostra applicazione, un sacco di “roba” viene aggiunta nel pannello di registrazione. Si tratta di tutte le richieste che la nostra applicazione fa.
Se ne selezioniamo una e clicchiamo sul bottone “comment” possiamo aggiungere un commento alla stessa che sarà possibile recuperare in un secondo momento.
Quando clicchiamo sul bottone “Stop”, succede “la magia”. Dapprima Visual Studio prende tutte le richieste e le informazioni dal web recorder plugin, le elabora e le inserisce nella finestra del webtest. Poi cerca di identificare se ci sono dei “parametri dinamici” nel nostro test.
I dynamic parameters sono tutti quei valori che possono cambiare se le richieste vengono fatte in momenti temporali differenti: user token, ricerche, autenticazioni, ecc. Se VS ne rileva qualcuno ci mostrerà una finestra in cui potremo decidere come e se utilizzarli. Possiamo selezionare di utilizzare per ogni iterazione di test esattamente quelli che sono stati registrati oppure se associare quei parametri ad una sorta di dizionario (che andremo a creare) da cui VS sceglierà di volta in volta valori differenti.
Un altro aspetto interessante che possiamo personalizzare riguarda i “Request details”. In questa finestra possiamo decidere se inserire dei “think time” tra le richieste (sostanzialmente dei ritardi) e, più importante, qual’è per noi il tempo “target” per le response. Se durante il test quella specifica richiesta avrà una response in un tempo maggiore di quello impostato come soglia, VS considererà il test come fallito.
Ora che abbiamo il webtest con tutti gli step ed i parametri impostati, possiamo finalmente aggiungere il progetto di Load Test alla nostra solution.
Il progetto di Load Test
Per aggiungere il test di carico ad un web performance test è sufficiente cliccare con il testo destro del mouse sul nome del progetto, scegliere “Add” e poi “Load test”.
Quest’azione farà comparire il “Load test wizard” che ci guiderà nel setup del test di carico.
Nel primo step dobbiamo scegliere se e come gestire i “think times” (i ritardi tra le request): possiamo usare gli stessi think time acquisiti durante la registrazione (attenzione che se mentre registravamo, tra un click e l’altro abbiamo fatto una pausa di ad esempio 5 minuti, durante il test quei 5 minuti saranno settati come delay tra quelle due richieste), possiamo scegliere “normal distribution” (che fa una sorta di media tra i tempi di delay registrati) oppure proprio di non usarne. Possiamo anche inserire un tempo di attesa tra iterazioni diverse dello stesso test.
Nel secondo step dobbiamo decidere quanto carico vogliamo generare verso la nostra applicazione e le modalità di generazione.
Possiamo selezionare di avere un carico costante (il test inizierà cioè con N utenti e continuerà con lo stesso numero di utenti fino alla fine) o di effetturare un test con “step load”.
Nell’immagine, ad esempio, ho deciso di utilizzare lo step load e di iniziare il test con 10 utenti aggiungendo ulteriori 10 utenti ogni 10 secondi, fino al raggiungimento di un massimo di 200 utenti.
Lo step load può essere molto interessante in quanto possiamo scoprire come (e se) la nostra applicazione scala in base all’incremento del carico applicativo.
Nello step successivo dobbiamo istruire il test di carico sul “cosa” fare. Per questa ragione inseriremo in questa schermata il web performance test che abbiamo creato precedentemente.
Cliccare su “Add”, selezionare il performance test che vogliamo, cliccare su “Ok” ed il test sarà aggiunto nella finestra “test mix”. Si chiama “Test Mix” perchè è possibile aggiungere quanti test vogliamo e se ne mettiamo più di uno possiamo definire la distribuzione percentuale di ognuno. In questo esempio abbiamo un solo test quindi la distribuzione sarà del 100%.
Possiamo anche decidere, negli step successivi, se e come utilizzare diversi tipi di connettività verso la nostra applicazione (attenzione: nel momento in cui scrivo VSO supporta solamente reti di tipo “LAN”) e che tipo di browser engine vogliamo che siano utilizzati dai test agent per effettuare le richieste.
Come potete vedere nell’immagine, possiamo scegliere da un elenco di molti browser ed anche in questo caso possiamo definire la distribuzione percentuale.
Nell’ultimo step possiamo personalizzare la durata dell’esecuzione del test.
Possiamo scegliere tra un tempo fisso oppure un numero di iterazioni di test. Se selezioniamo un tempo fisso (nel mio esempio 2 minuti), possiamo anche impostare un “Warm-up time” (10 secondi nell’esempio). Durante questo tempo verranno inviate alcune richieste all’applicazione per “risvegliarla” e non saranno collezionati dati. Questo comportamento è estremamente utile se dobbiamo testare applicazioni che necessitano di un cold start (come ad esempio webapp hostate su IIS che magari non sono state usate per un periodo di tempo e per le quali quindi IIS ha “disattivato” l’AppPool) per non avere dei falsi positivi nel risultato del test.
Cliccando su “Finish”, Visual Studio genererà il progetto di load test e lo salverà nella nostra soluzione.
Esecuzione del test
Ora che abbiamo tutto pronto possiamo eseguire il test. Ma prima, ancora un piccola impostazione. Noi vogliamo, infatti, che il test di carico sia eseguito attraverso la funzionalità Visual Studio Online Cloud Load Test ma nessuno l’ha detto al nostro Load Test project locale.
Per farlo bisogna aprire (doppo clic) il file “Local.testsettings” e cambiare il puntamento di “Test run location” su Visual Studio Online.
È da notare comunque che se abbiamo effettuato il login in Visual Studio con un account che ha una sottoscrizione a VSO questo step non sarà necessario in quanto VS seleziona direttamente questo valore per noi.
Ok, iniziamo il test cliccando sul bottone di start in alto a sinistra.
Ma cosa succede quando facciamo partire il test?
Visual Studio si connette a Visual Studio Online ed accoda il test. VSO poi crea on demand un lab virtual di test da qualche parte in un datacenter di Azure e configura i test agent sulle VM con i parametri settati.
Non appena il lab è pronto e configurato, il test parte. Se abbiamo configurato un periodo di warm up esso inizierà e potete vedere che non vengono collezionati dati.
Poi, finito il warm up, gli agenti iniziano a generare il traffico verso le pagine della nostra applicazione (così come utilizzate nella nostra registrazione) ed i risultati sono mandati al nostro Visual Studio quasi in tempo reale in modo da poter avere una preview del risultato finale del test.
Aspettiamo la fine del test per avere un resultset completo.
Risultati
Quando il test giunge al termine, verranno visualizzati tutti i risultati e le performance raggiunte. Le informazioni disponibili sono veramente moltissime.
Abbiamo i tempi di risposta medi, con anche il minimo ed il massimo, assieme ai tempi di test medi, i tempi di pagina medi ed il carico utente.
Possiamo vedere dal grafico e dalle info visualizzate che il numero di utenti virtuali è cresciuto nel tempo da 10 a 120 (avevo impostato un max di 200 ma non ha avuto tempo di raggiungere il massimo in quanto il test era limitato a soli 2 minuti con incrementi ogni 10 secondi) e come l’applicazione ha scalato al crescere del carico.
Anche nella sezione “Throughput” possiamo vedere molte informazioni utili.
In questo esempio non abbiamo avuto errori o parametri fuori soglia, ma se ci fossero stati avremmo visto un report degli stessi con le cause ed i messaggi di errore.
Questi sono però solo una piccola parte dei dati che abbiamo a disposizione. Se infatti clicchiamo sul link “download report” in alto, Visual Studio scaricherà l’intero resulset da Visual Studio Online rendendo disponibile, in questo modo, un report con una miriade di dati e grafici su ogni aspetto del test che ci aiuteranno a capire meglio come la nostra applicazione si comporta in uno scenario di carico.
Conclusioni
Questo tipo di Load test è il più completo che possiamo fare. Come potete vedere ci restituisce tantissime informazioni, metriche e grafici che ci permettono di analizzare il comportamento della nostra applicazione.
Inoltre, il setup di questi test è abbastanza semplice ma soprattutto è completamente personalizzabile ed in un poco tempo possiamo ottenere un gran numero di dati da poter consultare.
Il prossimo ed ultimo articolo di questa serie sarà sull’utilizzo delle Load Test APIs. Stay tuned!
Login