September 2011 Blog Posts

Va bene che il tester funzionale deve avere l’ambiente di test (magari virtualizzato con Lab Management) dedicato…

Va bene che devono essere situazioni controllate…

Va bene lo scenario…

…ma a me vengono in mente tante volte in cui il bug si presenta in modo improvviso Smile

Ergo in Visual Studio 11 è stato introdotto un nuovo tool a mio avviso estremamente utile: Microsoft Feedback Manager.

image

Feedback Manager estende quello che era il concetto di Test Manager in Dev10, aggiungendo la possibilità di catturare un video istantaneamente (ossia senza necessità di impostare ambienti ecc.) e di mandarlo direttamente in Team Foundation Server.

Il risultato sarà un bug con allegato video (piu tutte le varie informazioni sul sistema, che sarà poi inserito in Team Foundation Server come “General Feedback”.

Un’altra delle novità di Team Foundation Service è la possibilità di utilizzare dei Build Controller on premise (mentre, ovviamente, il resto del TFS è nel cloud).

La configurazione è esattamente la stessa rispetto ad un Build Controller tradizionale, l’importante è che si tratti di Dev11 Smile

Il build agent si può installare praticamente su tutto ciò che faccia girare una qualunque (Vista, 7, Server 2008, Server 2008 R2, 8, Server 8) versione di Windows, sia on premise (dominio o workgroup) che nel cloud (Azure VM Role, Amazon VM). Brian Harry lo ha installato sul pc del figlio, per dire Winking smile

Bene, a //build/ hanno annunciato Team Foundation Service. E ora? Smile

Innanzitutto io ho ancora qualche invito a disposizione, quindi se c’è qualcuno interessato batta un colpo Smile

A seguire, una volta che mi sono registrato alla preview, cosa devo fare?

Innanzitutto scaricare ed installare la patch (KB2581206) che aggiunge il supporto verso le istanze di TFService in Visual Studio, dal portale di amministrazione oppure qui.

Dopodichè bisogna creare un Team Project. Dalla pagina di Administration basta cliccare su create team project

image

aggiungere qualche dato (nome e descrizione del progetto, Process Template da utilizzare) e ci siamo Smile

image

Dopodichè in Visual Studio aggiungete il server TFS con i seguenti parametri:

  • vostronomeistanza.tfspreview.com
  • HTTPS – porta 443

Vi loggate con Windows Live, e selezionate il progetto come se fosse in locale.

Fine Smile

A //BUILD/ è stata finalmente annunciata una prima preview di Team Foundation Service (ossia Team Foundation Server su Windows Azure). Di seguito vi elenco una lista di cose che, utilizzandolo da diverso tempo, vi consiglio di sapere prima di iniziare ad utilizzarlo Smile

· E’ un servizio in preview, come tale non c’è ancora una SLA certa. Spesso si effettuano interventi di manutenzione e aggiornamento della piattaforma, quindi non prendetevela se vi comunicano qualche ora di downtime Smile

· Attualmente è gratuito, ma sarà previsto un piano di pagamento dalla versione RTM in poi (niente addebiti per la roba precedente insomma).

· I dati che metterete all’interno non verranno cancellati e verranno sempre mantenuti durante gli aggiornamenti della piattaforma, ma c’è un limite di circa 16 GB.

· Per ora Team Foundation Service è ospitato solo a Chicago, ma per la RTM sarà altamente disponibile come tutti i servizi di Azure.

· Non esiste ad oggi una procedura di migrazione da e verso TFService.

Passo e chiudo Smile

Il ruolo della Continuous Integration all’interno della Continuous Software Delivery è essenziale, strutturale.

Partiamo dall’idea che la CI è un cambio totale di paradigma: se prima il software non funzionava quando qualcuno provava la configurazione, ora invece è sempre automaticamente verificato (considerando anche l’esecuzione di test automatizzati) ogni volta che viene inserito nel Source Control un qualche tipo di cambiamento.

Implementarla con Team Foundation Server è facilissimo: basta indicare nella Build Definition che si tratta di una build eseguita in CI:

image

ed ovviamente deve esistere almeno un Build Controller con un Build Agent, altrimenti Visual Studio restituirà un errore.

Per utilizzarla con profitto è necessario che i check in siano eseguiti con regolarità e con una granularità accettabile, e che ci sia una suite di test automatizzati completa. Questa suite deve essere eseguibile sia sulla macchina di sviluppo che su quella di build in modo indifferente.

L’uso di uno strumento di segnalazione per lo stato della build è caldamente consigliato. Si può utilizzare di tutto: c’è stato un periodo in cui era esplosa la moda dei Nabatztag, dei conigli elettronici, e c’era chi lo aveva collegato alla build come strumento di segnalazione, per quanto si possono utilizzare anche strumenti più convenzionali come schermi che riportano lo status Smile

Nella Continuous Software Delivery è importante anche tenere in considerazione strumenti come Code Metrics, Code Coverage e Code Analysis: ci danno una panoramica di alto livello su alcuni specifici scenari (copertura da parte dei test per la Code Coverage, stile di scrittura del codice da parte della Code Analysis, metriche ingegneristiche per la Code Metrics) che spesso semplificano la fase analitica della risoluzione di un problema e portano ad un buon refactoring.

Il primo principio della Continuous Software Delivery dice di tenere tutto nel controllo di codice sorgente. Perchè?

All in a word: Configuration Management.

Se abbiamo automatizzare e rendere operativi gli ambienti di test, di staging, di produzione, la configurazione di server ed applicativi, e tutto quello che concerne la produzione di software, è necessario avere un repository centralizzato.

Quindi abbattiamo il “dogma” che vede solo il codice sorgente all’interno del VCS. All’interno del VCS dobbiamo avere tutto il necessario. Soprattutto le dipendenze giocano un ruolo chiave, visto che devono essere risolte in modo automatico.

Complementare ed altrettanto importante è avere dei messaggi che abbiano senso come commento al commit (changeset comments in Team Foundation Server), onde evitare di non sapere cosa stiamo prendendo ed il perchè dell’inserimento nel controllo di codice sorgente.

Aggiungo anche, che con i Team Foundation Server Power Tools, possiamo impostare delle regole (come quella che impone la scrittura di  changeset comments) che facilitano l’aderenza alle guidelines di team.

I check-in devono essere frequenti, e soprattutto eseguiti regolarmente nella trunk. Va prestata molta attenzione con le branch, visto che eseguire branch e poi scoprire problemi di integrazione al momento della merge è assolutamente antitetico alla Continuous Integration, che è fondamentale nel processo che stiamo analizzando. Strumenti di merge automatizzato non sono contemplati: le modifiche vanno unite a mano. Ci torneremo comunque su a tempo debito, se necessario Smile

Tornando all’argomento chiave del post, la configurazione, la possiamo dividere in sottocategorie in base al momento in cui viene modificata:

  • Build Time Configuration, ossia l’inserimento della configurazione al momento della creazione dei file binari
  • Packaging Time Configuration, qui la configurazione viene iniettata durante la creazione di un pacchetto distribuibile, ad esempio un .msi
  • Deployment Time Configuration, la configurazione viene solitamente catturata o inserita al momento dell’installazione
  • Startup Configuration, che è quella che esegue una applicazione in modo automatico all’avvio

Solitamente vengono utilizzate le ultime due. Ed ovviamente si deve aveere un repository centrale anche della configurazione, da trattare con gli stessi criteri del codice sorgente.

Bisogna tener conto anche che versioni di sviluppo, UAT, performance testing, staging e produzione possono avere diverse configurazioni. Il consiglio è di trattarla come codice sorgente, e di creare un sistema strutturato (XML, per dirne uno) di storage.

Le configurazioni vanno testate (si, si possono scrivere unit test anche per questo), e devono inesorabilmente fallire se qualche prerequisito o dipendenza non è installato/funzionante correttamente. il Visual Studio Lab Management in questo è assolutamente essenziale Smile

Il sistema di configurazione deve essere automatico e flessibile, e soprattutto seguire il principio DRY (don’t repeat yourself). Ripetere gli elementi di configurazione significherebbe ridondanza non necessaria e l’inserimento di ulteriori points of failure.

Questo è solo un piccolo tassello nella Continuous Delivery, nel prossimo…chissà Smile