venerdì 29 aprile 2016

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 :)


martedì 5 aprile 2016

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 (@marcominervaGitHub) per il supporto ed i suggerimenti.

giovedì 20 agosto 2015

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.

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

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.

lunedì 27 luglio 2015

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.

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!

martedì 16 giugno 2015

Creare un Reader RSS in una Partial View di Umbraco 7

Ci sono molti modi di creare ed includere un reader RSS in una pagina di Umbraco: usare un custom controller, usare delle marco XSL, ecc...

Ma se volessimo usare solamente una Partial View MVC senza sviluppare un controller custom?

Beh, è veramente semplice raggiungere questo obiettivo con solo pochissime righe di C#

@inherits Umbraco.Web.Mvc.UmbracoTemplatePage
@using System.ServiceModel
@using System.ServiceModel.Syndication
@using System.Xml
@{
 string url = "http://your_blog_rss_url";
 XmlReader reader = XmlReader.Create(url);
 SyndicationFeed feed = SyndicationFeed.Load(reader); 
 reader.Close(); 
}

@foreach(var feedItem in feed.Items)
{ 
 <div class="col-md-6">
  <article>
   <div class="date">
    <span class="day">@feedItem.PublishDate.Day</span>
    <span class="month">@GetMonthName(feedItems[i].PublishDate.Month)</span>
   </div>
   <h4 class="heading-primary"><a href="@feedItem.Links[4].Uri">@feedItems[i].Title.Text</a></h4>
   <p>@(feedItem.Summary.Text + "... ") <a href="@feedItem.Links[4].Uri" class="read-more">read more <i class="fa fa-angle-right"></i></a></p>
  </article>
 </div>
}

Come potete vedere, sono bastate alcune righe di codice ed abbiamo il nostro Reader RSS. A questo punto è necessario semplicemente includere questa partial view nella pagina che ci interessa per vedere il nostro feed RSS.
Ovviamente è possibile cambiare il layout, quello nell'emepio è solo quello che ho usato io per il mio progetto.

Solo 2 note:
  1. Io ho usato "feedItem.Links[4].Uri" per recuperare l'url del blog post, questo funziona se si usa blogger come hoster. Se invece utilizzate altre piattaforme di blogging, dovrete scorrervi la collection Links per scoprire dov'è l'url che vi serve.
  2. Il "@GetMonthName" è solamente un Helper che converte il "numero" del mese nel suo nome.

lunedì 8 giugno 2015

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! :)

lunedì 19 gennaio 2015

Cloud Load Test con Visual Studio Online - parte 1: Web panel

Questo articolo è il primo di una serie di 3 in cui parlerò di Cloud Load Testing con Visual Studio Online.

In questa prima parte affronterò l'esecuzione di test di carico semplici su applicazioni web, utilizzando direttamente le funzionalità messe a disposizione dal portale di VSO.

Introduzione
Prima di iniziare a parlare nello specifico dell'esecuzione dei Cloud Load Test è importante soffermarsi su 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 (al tool va indicato l'url da testare)
  • Gratuitamente si possono utilizzare fino a 15.000 minuti al mese. Si tratta di "virtual user minutes", quindi ad esempio eseguendo 1 test da 2 minuto con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.


Fatte queste precisazioni, vediamo come si possono eseguire i test di carico utilizzando l'iterfaccia presente sul portale di Visual Studio Online.


Iniziamo
Innanzitutto è necessario fare login al portale web di VSO e, dalla dashboard iniziale scegliere "Load test".


Fatto questo viene proposta la finestra di impostazione delle variabili del test. Come vedete si tratta di un unica schermata, quindi  le impostazioni possibili sono abbastanza limitate, ma comunque sufficienti a fare un test di carico generico sulla nostra applicazione.


Come prima cosa viene chiesto l'url su cui eseguire il test di carico: si tratta di un solo url (quindi non è possibile eseguire da qui un test di carico a step consecutivi o a navigazione pseudo-reale) che può corrispondere all'home page del sito o, come nell'esempio, ad una qualsiasi pagina della web application. L'unico vincolo presente è che la pagina deve essere visibile pubblicamente senza necessità di inserire delle credenziali, visto che al momento non è possibile impostarle.

Il secondo parametro da inserire è il nome del test: si tratta di una stringa libera, che servirà a noi solo come reminder.

Sotto questi due parametri ce ne sono altri 4, indicati proprio come "Test settings", che servono per poter meglio definire gli aspetti chiave del carico che si vuole applicare.

  • User Load: permette di definire il numero di utenti virtuali che contemporaneamente si collegheranno all'url fornito. I valori possibili sono 25, 50, 100 e 200
  • Run duration: è la durata complessiva del test. I valori selezionabili sono da 1 a 5 minuti
  • Think-time: si tratta del tempo di attesa tra una richiesta e l'altra. Serve per evitare che i sistemi di anti-hammering e anti DoS entrino in funzione. È possibile indicare tempi di attesa di 1 secondo (default) o 5 secondi
  • Browser distribution: questa impostazione indica la percentuale di utilizzo di browser che si vuole simulare. Scegliendo ad esempio "IE 80%, Chrome 20%" il test verrà eseguito con agenti useranno gli engine di Internet Explorer e di Chrome nelle percentuali selezionate


Settate queste impostazioni, cliccando sul bottone "Test now" si da inizio al test.


Esecuzione del Test
Ma cosa avviene, nel concreto quando si avvia il test?
Visual Studio Online crea per noi on demand un lab virtuale in un datacenter su Azure e configura gli agenti sulle vm con i parametri indicati:



Non appena il lab è pronto e configurato, inizia il vero e proprio test di carico. Gli agenti iniziano a generare traffico verso l'url indicato e i risultati sono inviati, quasi in real time, al nostro browser. In questo modo possiamo avere un'anteprima dell'esito del test.


In questa immagine vediamo, ad esempio, che intorno ai 50 secondi si è verificato "un buco" nelle richieste al secondo che il sito è risucito a gestire, testimoniato anche dal notevole incremento del tempo di risposta. Utilizzando questi dati potremmo avviare un'attività di analisi sulla nostra applicazione o sulla nostra infrastruttura per capire come mai si sia verificata un'anomalia del genere.


Risultati
Al completamento del test, ci vengono indicati gli esiti e le performance raggiunte.
Oltre al grafico che avevamo anche durante l'esecuzione ci vengono date altre informazioni.


Innanzitutto ci viene data l'indicazione tel tempo di risposta medio. Un tempo medio inferiore a 0,1 secondi è considerato buono. tra 1 secondo e 0,1 secondi è considerato "non molto buono", sopra il secondo è considerato negativo.

Dopo il tempo di risposta, è indicato il numero di richieste che in totale sono state fatte alla web app.

Infine, c'è l'indicazione delle eventuali richieste che non sono andate a buon fine o che hanno generato un errore sull'applicazione.

Sotto questi valori viene indicato anche quali errori sono stati riscontrati.


In questo caso non ve ne sono, se si fossero verificati degli errori nella tabella troveremmo la causa generica dell'errore, il suo tipo specifico ed il messaggio di errore.


Conclusioni
Questo tipo di Load test non è sicuramente il più completo che si possa ottenere, ma va comunque bene se ci interessa avere delle indicazioni di massima sulle prestazioni e sul carico supportato dalla nostra applicazione.
Inoltre il setup di questi test è estremamente semplice e in pochissimi minuti si è in grado di avere un gran numero di informazioni utili.

Se quello di cui avete bisogno, invece, è un test approfondito, eseguibile simulando un flusso reale di navigazione... non perdetevi il mio prossimo articolo di questa serie.

venerdì 19 dicembre 2014

Edit dei file di codice sorgente da Web con Visual Studio Online

Brian Harry, sul suo blog, ha annunciato il nuovo rilascio di Visual Studio Online; rilascio che comprende anche l'attesa funzionalità di editing del codice direttamente dal portale web.
Vediamo come funziona.
 
 
Edit
Dopo essere entrati sulla Dashboard del Team Project che vogliamo gestire, andiamo sulla sezione "Code" e selezioniamo dal menù ad albero di sinistra uno dei file di codice sorgente.
 
Sulla destra si aprirà, come al solito, la schermata in sola lettura che contiene il codice. A differenza di quanto succedeva precedentemente, però, è disponibile un nuovo bottone "Edit".
 
 
Cliccando sul bottone, succederanno tre cose:
  1. La toolbar cambierà visualizzazione
  2. Nel menu ad albero il file selezionato verrà "marcato" con un * ad indicare che è in modifica
  3. Nella schermata sarà possibile apportare modifiche al codice sorgente
 
 
Una volta completata la modifica, è possibile (consigliato, a dire il vero...) inserire un commento nella textbox che verrà associato al checkin e premere sul pulsante di salvataggio (comparso nella toolbar).
 
Cliccato su "Save", la modifiche vengono salvate sul source control, viene creato un changeset e viene visualizzato un tooltip che ci informa dell'esito positivo dell'operazione, con un link alla visualizzazione del changeset stesso.
 
 
È anche possibile annullare le modifiche utilizzando il bottone "Discard", sempre nella toolbar.
Infine, se prima di fare il checkin vogliamo verificare le modifiche apportate, è possibile fare una diff tra il file residente sul source control e la nostra versione, utilizzando il pulsante all'estrema destra della toolbar.
 
 
  
Upload, Create, Rename, Delete
Oltre a modificare direttamente i sorgenti, è possibile anche rinominare, cancellare e creare file e cartelle e fare l'upload di nuovi file.
 
 
Per creare un nuovo file o farne l'upload basta cliccare con il tasto destro su una cartella e scegliere "Add file(s)".
Si aprirà un popup in cui si può scegliere se creare un file nuovo o se scegliere dei file già esistenti da caricare.
 
 
Viceversa, per cancellare un file cliccarci sopra con il tasto destro e scegliere "Delete" (viene chiesta conferma).
 
Per rinominarlo, infine, sempre dal menù contestuale che appare con il tasto destro scegliere "Rename".
 
Tutte queste operazioni genereranno un changeset, quindi le modifiche saranno mappate e storicizzate sul source control.

mercoledì 12 novembre 2014

Aggiungere Azure Application Insights ad un Web Site

Sviluppando una Web Application, è possibile usare Visual Studio 2013.3 per aggiungere automaticamente tutte le librerie e le configurazioni di cui "Azure Application Insights" ha bisogno pre funzionare.
 
Ma invece per quanto riguarda i Web Sites? Se si crea un Web Site (oppure si vuole modificarne o gestirne uno già esistente) l'opzione per aggiungere l'Application Insights non è presente. Cosa possiamo fare, quindi? Com'è possibile raggiungere lo stesso risultato? Come possiamo integrare Azure Application Insights in un Web Site?
 
È possibile! Basta seguire questi step:
  1. Creare un nuovo servizio "Application Insights" usando il nuovo Azure portal (preview)
  2. Copiare lo snippet di codice JavaScript che viene proposto dal portale ed aggiungerlo a tutte le pagine che si vogliono monitorare (oppure alla master page, se ce n'è una)
  3. In Visual Studio 2013.3, creare una nuova web application vuota ed aggiungere ad essa Application Insights usando il menu contestuale
  4. Copiare i seguenti file dalla cartella "bin" della Web App alla cartella "bin" del Web Site:
    Microsoft.ApplicationInsights.dll
    Microsoft.ApplicationInsights.Extensibility.RuntimeTelemetry.dll
    Microsoft.ApplicationInsights.Extensibility.Web.dll
    Microsoft.Diagnostics.Tracing.EventSource.dll
    (volendo è possibile anche copiare i relativi file .xml e .pdb)
    
  5. Tornare nell'Azure portal (preview), andare nella sezione dell'Application Insights creato precedentemente, cliccare sul bottone "Properties" e copiare il valore della texbox "Instrumentation Key"
  6. Copiare il file ApplicationInsights.config dalla root della Web App alla root folder del Web Site
  7. In questo file, sostituire il valore della chiave "InstrumentationKey" con quello copiato al punto 5
  8.  Cambiare il file web.config del website aggiungendo le seguenti righe:
    <system.web>
     [...]
        <httpModules>
       [...]
          <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" />
       [...]
        </httpModules>
     [...]
    </system.web>
    
    <system.webServer>
     [...]
        <validation validateIntegratedModeConfiguration="false" />
     [...]
     <modules runAllManagedModulesForAllRequests="true">
       [...]
          <remove name="ApplicationInsightsWebTracking" />
          <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" preCondition="managedHandler" />
       [...]
        </modules> 
     [...]
    </system.webServer> 
    
 
A questo punto è possibile avviare e testare il Web Site e, dopo qualche secondo, i dati e le statistiche saranno presenti nella blade dell'Application Insights (sempre sul nuovo Azure portal)

martedì 11 novembre 2014

Gestire i Cloud Load Test con le REST API

Le REST API dei Cloud-based Load Testing (CLT) permettono di automatizzare l'esecuzione dei Load test dal Cloud, in modo da poterli integrare nei processi di Continuous Integration / Deployment e di Test Automation.

Ecco una lista (sicuramente in espansione) di quello che si può fare con queste nuove API:
  • Creare / Lanciare / Stoppare un Load Test Run
  • Recuperare i Load Test Results - un set di gruppi di  KPI - Performance, Throughput, Application
  • Recuperare i Messages del servizio durante l'esecuzione
  • Recuperare le Exceptions, se ci sono
  • Recuperare le Counter instances di un  Load Test run
  • Recuperare gli Application Counters delle App configurate nel load test
  • Recuperare una lista di tutti i Load test Runs eseguiti - con filtri per requester, date, status ecc..
Queste API lavorano in stretta vicinanza con le Azure API, visto che si leggono i test file da un Azure Blob e salvano i risultati nella stessa drop folder sempre sull'Azure Blob.

È importante notare che:
  • Per usare le REST API, è necessario abilitare le alternate credentials su Visual Studio Online e quindi utilizzarle per l'autenticazione
  • Aggiungere"vsclt" al nome dell'account VSO per essere rediretti al "Cloud-based Load Test (CLT) service" di visualstudio.com. Ade sempio, se l'account è https://abc.visualstudio.com/, quando si utilizzano le API indicare https://abc.vsclt.visualstudio.com/
 
Il pattern di base per le  API è il seguente:
VERB    https://{account}.vsclt.visualstudio.com/_apis/clt/{resource}[/{options}]
 
Dove "resource" può essere una delle seguenti e le "options" dipendono dalla resource:
 
Test
  • Per i "Test Runs": testruns
  • Per le "Test Drops" (i container dove vengono salvati i dati): testdrops
 
Dipendenti dai Test Run
  • Per le "Counter Instances": testruns/{testrunid}/counterinstances
  • Per i "Counter Samples": testruns/{testrunid}/countersamples
 
Application Performance Management:
  • Per i "APM Plugins": apm/plugins
  • Per le "APM Applications ": apm/applications
  • Per i "APM Counters ": apm/counters

Creare un Test Run
Per creare un Cloud Load Test Run, è necessario fare una chiamata POST alle API, passando nel body un set di parametri e test settings come in questo esempio.

Request Url:
POST    https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns

Request Body:
{
  "name": "MyAppToTest.loadtest",
  "description": "nightly loadtest",
  "testSettings": {
    "cleanupCommand": "",
    "hostProcessPlatform": "x86",
    "setupCommand": ""
  },
  "testDrop": {
    "id": "fe35ed32-eaab-4178-ba7e-ad2577ee187f"
  }
}


Response:
{
  "id": "a5e0d4b9-d387-4b3e-9566-163da9c39b67",
  "name": "MyAppToTest.loadtest",
  "createdDate": "2014-11-1T08:51:27.0965365Z",
  "state": "pending",
  "subState": "none",
  "testSettings": {
    "cleanupCommand": "",
    "hostProcessPlatform": "x86",
    "setupCommand": ""
  },
  "testDrop": {
    "id": "fe35ed32-eaab-4178-ba7e-ad2577ee187f",
    "url": "https://dbtek.vsclt.visualstudio.com/_apis/clt/TestDrops/fe35ed32-eaab-4178-ba7e-ad2577ee187f"
  },
  "runSpecificDetails": {
    "duration": 180,
    "virtualUserCount": 250,
    "samplingInterval": 15
  },
  "createdBy": {
    "id": "76cabfe4-0e20-4f5b-862e-9693a68232f1",
    "displayName": "iamtheuser@dbtek.it"
  },
  "url": "https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns/a5e0d4b9-d387-4b3e-9566-163da9c39b67"
}


Come si può vedere, nella response si trovano tutti i dati che possono servire relativi al test run appena creato.

Avviare un Test Run
Con questi dati possiamo per esempio avviare (o meglio accodare) il test run, chiamando le API usando un verb PATCH:

Request Url:
PATCH    https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns/a5e0d4b9-d387-4b3e-9566-163da9c39b67

Request Body:
{
  "state": "queued"
}


Response:
Status code: 202


Recuperare i Test results
Infine, quando il test è finito, possiamo recuperare i risultati con una call in GET.

Request Url:
GET    https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns/a5e0d4b9-d387-4b3e-9566-163da9c39b67/results

Response:
{
  "resultsUrl": "http://127.0.0.1:10000/devstoreaccount1/ets-containerfor-aeee0697-d734-43d7-956e-e662252c265c/2150fbd4-e71c-42fd-8b90-95222a556d87/TestResult/LoadTest.ltrar.zip?sv=2012-02-12&se=2014-06-03T05%3A05%3A39Z&sr=b&si=sas_tenant_policyaeee0697-d734-43d7-956e-e662252c265c&sig=n1Tj%2BsCtiOqQu9UtcXsl%2Bn3ixP%2FVebHCKDJvfD5Tr%2FE%3D",
  "counterGroups": {
    "count": 3,
    "value": [
      {
        "groupName": "Performance",
        "url": "https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns/a5e0d4b9-d387-4b3e-9566-163da9c39b67/CounterInstances?groupNames=Performance"
      },
      {
        "groupName": "Throughput",
        "url": "https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns/a5e0d4b9-d387-4b3e-9566-163da9c39b67/CounterInstances?groupNames=Throughput"
      },
      {
        "groupName": "Application",
        "url": "https://dbtek.vsclt.visualstudio.com/_apis/clt/testruns/a5e0d4b9-d387-4b3e-9566-163da9c39b67/CounterInstances?groupNames=Application"
      }
    ]
  }
}



Recuperare i Test errors
È anche possibile recuperare una lista di eventuali errori che si sono verificati durante l'esecuzione del test. Di nuovo, va utilizzata una chiamata in GET.

Request Url:
GET    https://dbtek.vsclt.visualstudio.com/_apis/clt/testRuns/47be20f0-ac4a-40cd-acb7-d9f8c44d0404/Errors

Response:
{
  "count": 2,
  "value": [
    {
      "type": "Exception",
      "subType": "UriFormatException",
      "occurrences": 50,
      "testCaseName": "ErrorsAndExceptionsWebTest",
      "scenarioName": "LoadTestingScenarioWarmupDuration",
      "request": "http://www.bing:123.com/----{GET}",
      "stackTrace": "   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)\n   at System.Uri..ctor(String uriString, Boolean dontEscape)\n   at Microsoft.VisualStudio.TestTools.WebStress.WebTestTransaction..ctor(String requestUrl)\n   at Microsoft.VisualStudio.TestTools.WebStress.WebTestInstrumentedTransaction.CreateTransaction()\n   at Microsoft.VisualStudio.TestTools.WebStress.WebTestInstrumentedTransaction.Execute(WebTestCaseContext testCaseContext, AsyncCallback completionCallback, Object callerState)",
      "messageText": "Invalid URI: Invalid port specified.",
      "lastErrorDate": "2014-11-11T09:14:20.363Z"
    },
    {
      "type": "ExtractionRuleError",
      "subType": "ExtractText",
      "occurrences": 50,
      "testCaseName": "ErrorsAndExceptionsWebTest",
      "scenarioName": "LoadTestingScenarioWarmupDuration",
      "request": "http://www.bing.com/----{GET}",
      "stackTrace": "",
      "messageText": "StartsWith text was not found in the response",
      "lastErrorDate": "2014-11-11T09:14:23.663Z"
    }
  ]
}