La nuova iterazione di sviluppo segue il già citato Iteration Planning in cui sono state individuate le Storie da realizzare in funzione degli obiettivi da raggiungere. Se lavorate in chiave Kanban/Lean potreste non avere un concetto esplicito di “Iterazione”, ma comunque avrete dei momenti in cui considerate l’Increment attuale “ready to…” e passerete ad identificare un goal successivo scegliendo le Storie annesse.
Quando parliamo di sviluppo intendiamo sia la scrittura del codice sia i relativi test di unità annessi: nel mondo DevOps/Agile nessuna Feature/Storia può essere ritenuta completata se non adeguatamente corredata dei relativi Unit Test.
Develop and Test
Lo strumento centrale di VSTS per seguire le attività di sviluppo è l’Iteration Backlog, annesso alle iterazioni definite in modo esplicito attraverso le relative impostazioni:
Iterazioni
Una volta settate le iterazioni di riferimento, si procede con l’assegnazione specifica dei work item da realizzare, andando contestualmente a identificare i task di lavoro specifici. Il consiglio è di farlo solo per l’iterazione in partenza, e al massimo la successiva, in modo da evitare di spendere tempo su cose che potrebbero essere successivamente profondamente riviste.
Sprint Board
Se durante la pianificazione dell’iterazione si utilizza un approccio basato sulle stime in Story Point e si tiene d’occhio la Velocity, è possibile sfruttare l’estensione Easy Estimation che consente di eseguire il Planning Poker direttamente online in VSTS.
Easy Estimations
L’andamento delle attività di sviluppo può essere monitorato grazie al Cumulative Flow Diagram (qui un precedente approfondimento a tema), alla Velocity e all’Iteration/Sprint Burndown. Si tratta di strumenti molto utili che devono, però, essere utilizzati in un’ottica di Continuous Improvement e non di controllo delle attività da parte del management.
Cumulative Flow Diagram (CFD)
Iteration/Sprint Burndown
Velocity diagram
Analogamente, gli strumenti di Forecasting (previsione) e di Capacity (allocazione del team), possono essere utili per i team Agili alle prime armi, ma già dopo 4-5 iterazioni hanno una utilità meno incidente nel processo di miglioramento ai diversi livelli operativi.
Va detto che in perfetta sintonia con il secondo valore del Manifesto Agile (SOFTWARE FUNZIONANTE più che la documentazione esaustiva), lo scopo primario di questa fase è quella di scrivere software funzionante e diversi sono gli strumenti MS che agevolano tale attività: Visual Studio IDE, il Version Control System, il Sistema di Building e di Continuous Integration di VSTS. Tutti rappresentano un insieme di soluzioni estraneamente efficaci che aiutano gli sviluppatori, e non solo, a raggiungere proficuamente i propri obiettivi.
Come già ribadito, il codice deve sempre essere corredato dai relativi Unit Test automatizzati, e l’utilizzo di MSTest, o di una delle implementazioni di xUnit, consente di assolvere egregiamente a questo compito, andando a creare per ogni progetto della nostra solution un progetto parallelo di testing che ne raccoglie la relativa batteria di test automatizzati.
Unit Testing Project
Dopo la sua elaborazione, tutto quanto afferisce alla soluzione viene salvato nel Version Control System di riferimento, Team Foundation Version Control (TFVC) o Git, entrambi gestiti in modo nativo da VSTS ed integrati nella console di gestione dell’IDE. L’evidenza delle motivazioni che portano a scegliere l’uno o l’altro esula dallo scopo di questo approfondimento, anche se è importante evidenziare che, nelle soluzioni enterprise, Git è diventato uno standard de facto. Questo perché consente di lavorare in modo più flessibile in un ambiente organizzativo ampio e distribuito, favorendo diverse politiche di branching. La scelta di Git abilita, inoltre, alla possibilità di utilizzare le Pull Request, un importante strumento di code review che può essere sfruttato per chiedere un parere sul codice scritto, ricevendo suggerimenti in merito e discutendo delle ultime modifiche apportate. Se alla fine della review la pull request viene accettata, il codice viene unito (merge) al resto della base line. Per completezza bisogna evidenziare che una funzionalità similare, chiamata Code Review, è disponibile anche per chi utilizza TFVC.
Pull Request
Nel caso quanto realizzato sia affetto da anomalie, o si riscontrino difficoltà operative, si può ricorrere ai work item di tipo Bug ed Incident per tracciarne la presenza (di cui si è parlato nel post precedente). Da un punto di vista operativo, per migliorare la qualità del codice, oltre a sfruttare le Pull Request/Code Review, è possibile utilizzare una serie di strumenti specifici messi a disposizione dall’IDE Visual Studio: Code Analysis, che consente di validare il codice in funzione di un set di regole personalizzabili, Code Metrics, che fornisce tutta una serie di metriche di valutazione (linee di codice, complessità ciclomatica, accoppiamento e la profondità dell’ereditarietà) e Clone Code Analysis, per cercare codice clonato e/o ripetuto.
Quando il codice e i test hanno raggiunto il “done state” e il tutto è salvato nel VCS di riferimento del progetto, si passa alla Gestione delle Build e all’azione di Continuous Integration. Entrambe sono gestiste in modo estremamente lineare da VSTS, a partire dalla build definition che permette di definire tutti i passi specifici nei minimi dettagli, consentendo, anche, di creare azioni personalizzate in funzione delle proprie esigenze.
Build Definition
L’azione di Continuous Integration viene attivata abilitando il relativo trigger che scatena una nuova build ad ogni commit. Va specificato che esistono comunque anche “soluzioni aggreganti” per evitare di sovraccaricare inutilmente gli agent relativi.
Continuous Integration
La presenza di validi test, come più volte ribadito essenziali per attuare concretamente l’azione di Continuous Integration, consente di evidenziare velocemente i problemi sugli ambienti di riferimento e non solo sulle workstation dei dev (“ma sulla mia macchina funzionava”), intervenendo rapidamente in caso di problemi. Ciò evita che questi ultimi si sommino tra loro, rendendo difficile individuarne la fonte e risolverli, e portando ad un aumento del Debito Tecnico.
Full Continuous Integration actions
La qualità di quanto realizzato può essere ulteriormente analizzata sfruttando l’integrazione (a livello di Build/CI) con SonarQube, che estende le funzionalità di verifica all’intero codice facente parte della build. Si tratta di uno strumento molto potente, che si integra con VSTS in modo diretto e consente di scandagliare tutto il codice alla ricerca di problemi e percorsi critici noti.
SonarQube Build Tasks
Da evidenziare che i task di integrazione fanno parte del nuovo modello di estensione gestito direttamente da Sonar e che i precedenti in-bundle, realizzati da Microsoft, sono ora marchiati come deprecati e verranno rimossi nei prossimi aggiornamenti.
Sempre in ambito testing, ma di tipo A/B o Canary, è interessante segnalare LaunchDarkly che consente di abilitare e disabilitare specifiche funzionalità direttamente da una console di controllo. L’obiettivo primario può essere di due tipi: testare le nuove Feature da un punto di vista funzionale, ossia verificare che facciano quanto previsto, e validarne l’effettiva utilità (in chiave Lean Startup). In pratica, se si considerano due popolazioni (insieme di utenti) diverse, A e B, che utilizzano il servizio, e quella A, alla quale sono state attivate le nuove Feature, non mostra alcun interesse in esse, probabilmente le stesse non sono particolarmente utili.
A/B Testing
L’utilizzo di LaunchDarkly prevede di inserire all’interno del proprio codice poche istruzioni (vi consiglio caldamente di utilizzare un design basato su Dependency Injection) che poi consentiranno di controllare l’attivazione/disattivazione delle funzionalità da un comodo pannello di controllo web-based.
LaunchDarkly Dashboard
L’azione di Build può concludersi con la creazione di un Container, e in VSTS non poteva mancare il supporto nativo a Docker, o anche con la pacchettizzare della soluzione per poter essere gestita con i più comuni package manager, NuGet in primis.
Chiudiamo la trattazione dell’area Develop and Test facendo un rapido richiamo a due applicativi dell’ecosistema Office 365 particolarmente interessanti. Il primo è Planner, che consente di gestire le attività ad un livello di pianificazione generale, sempre in chiave Kanban/Visual Management.
Office 365 Planner
Il secondo è Teams, integrabile con VSTS, che consente di comunicare in modo meno formale e più efficace con i membri del team di progetto. In Teams è possibile utilizzare dei Bot che consentono di analizzare le informazioni e offrire suggerimenti, oltre a creare implicitamente una knowledge-base basata sulle discussioni.
Office 365 Teams
Post precedenti della serie:
