DA2, Development strategies

Le strategie suggerite da DA2 per Disciplidned DevOps consentono, come detto, l’abbattimento dei Silos organizzativi in funzione di una Cultura condivisa e in funzione del comune obiettivo di migliorare il processo di Delivery.
Ripartendo dal post precedente, diamo uno sguardo al primo insieme di elementi strategici (primo solo per ordine di elencazione), ovvero quello relativo al Development, in cui le azioni si concentrano sul migliorare la validazione e il passaggio tra gli ambienti di quanto realizzato:

  • Canary Test: si tratta di una pratica pensata per validare le potenzialità, di interesse e di revenue, di una nuova feature, proponendola ad un gruppo di “early adopter” e quindi dispiegandola in una sandbox che non richiede particolari azioni di deployment. Questo test e’ estremamente utile per ottenere feedback diretti e solo successivamente rinforzare quanto realizzato e attivare tutti gli aspetti della pipeline di Delivery;
  • Split Test (anche A/B Test): si tratta di una pratica in cui diverse opzioni relative alla stessa feature, vengono realizzate e fatte girare in produzione per determinare “sul campo” quale di essa e’ la più efficace. Normalmente gli utenti vengono segmentanti in differenti gruppi e ognuno di esso lavora con una sola delle implementazioni. I sistemi di monitoraggio passivo, tipo monitor o logging, fornisco le necessarie informazioni per la scelta;
  • Automated Regression Testing: l’utilizzo di batterie di test di regressione permette di garantire un livello relativo di qualità e promuovere per il deployment solo le build affidabili, in modo da ridurre il più possibile gli annessi problemi in produzione e, di riflesso, il carico di attività di Ops. In particolare è sempre buona pratica definire diverse batterie di regression test, potendo questi ultimi diventare onerosi da eseguire;
  • Continuous Integration (CI): consente di ottenere (potenzialmente) ad ogni commit delle modifiche, nel Version Control System, una nuova Build della soluzione, integrata e sottoposta ai diversi livelli di test, da quelli funzionali a quelli di regressione di cui sopra;

da2 ci

Continuous Integration process

  • Continuous Delivery (CD): è lo step immediatamente successivo a quello di CI, in cui la Build validata viene promossa automaticamente al successivo ambiente, ad esempio in quello di pre-produzione, dove vengono effettuate ulteriori azioni di test/verifica/validazione. Se tutte le azioni annesse sono automatizzate, e’ possibile, in ultimo, raggiungere direttamente la produzione (Continuous Deployment). Questa strategia consente di ridurre fortemente il gap dalla richiesta di una nuova feature alla sua messa in erogazione (lead time), ma richiede una forte disciplina nello sviluppo al fine di evitare che il prodotto dispiegato automaticamente sia affetto da errori importanti il cui costo aumenta significativamente in relazione all’ambiente in cui si interviene

da2 cd

Continuous Delivery process

  • Development Intelligence: si tratta di un sub-set dell’IT intelligence (si veda Data Management Strategies), focalizzato sugli aspetti di sviluppo. In pratica, grazie a Dashboard popolate dai diversi tool utilizzati, e’ possibile avere un quadro di come procede l’attività complessiva e sui punti su cui intervenire per migliorare il tutto. Con “tool” non si intendono solo quelli digitali, ma anche, ad esempio, quelli “materiali” tipici del mondo Agile/Lean come la Kanban board.

Oltre a queste strategie development-friendly, in chiave DevOps, i team di dev possono adottare una serie di accorgimenti (operations-friendly feature) utili per supportare il dispiegamento della soluzione:

  • Feature access control: utile soprattutto per supportare le strategie si sperimentazione, come Canary e Split. Si basa sulla possibilità di attivare e disattivare rapidamente specifiche funzionalità tramite un file di configurazione facilmente modificabile;
  • Monitoring instrumentation: sono strumenti di monitoraggio passivo, ad esempio il log degli eventi di sistema, che consentono di monitorare il funzionamento dell’applicazione, sia da un punto di vista dell’erogazione/efficienza e sia da un punto di vista funzionale, ossia di cosa viene realmente utilizzato nell’applicazione;
  • Feature toggles: è una pratica che contempla l’attivazione di un insieme di funzionalità in relazione a diversi scenari di utilizzo: si pensi alle soluzioni SaaS e ai diversi livelli di contratto annesso;
  • Self-testing: questo approccio permette ad un’applicazione di auto-testarsi e segnalare il proprio stato. Ciò avviene attraverso la presenza di una serie di funzionalità minimali di test dispiegate con il prodotto: si immagini, come esempio,, ad un is-alive test che verifica periodicamente la disponibilità del servizio db;
  • Self-recovery: si tratta arricchire il software con funzionalità che permettono di rispondere a situazioni di errore, tentando di ripristinare lo stato desiderato o di tamponare con soluzioni di ripiego. Si pensi, ad esempio, ad un App Mobile che effettua transazioni su un db: se la connessione e’ giù, l’App può utilizzare un local store per continuare ad operare e poi sincronizzare il tutto appena la connessione e’ nuovamente disponibile.

Prima di chiudere e’ importante evidenziare che l’ordine con cui vengono presentate le strategie non è casuale, ma rispecchia l’effort e la maturità richiesta in senso crescente. Questo fattore e’ essenziale perché ricordiamo che DA2 e’ un framework Goal Oriented, in cui per ogni goal vengono suggerite possibili strategie da adottare in relazione al proprio contesto e alla specifica maturità raggiunta.

 

Stay tuned!

Creare un clone dell’istallazione di produzione di TFS con TFS “15”

Ho appena bloggato nel blog inglese una grossa novità dell’installer della nuova versione di TFS, che per ora è identificata con il nome TFS “15”. Nel nuovo wizard è presente una opzione per automatizzare tutte le procedure di creazione di un clone o istanza di Pre-Produzione del vostro TFS.

La necessità di clonare l’ambiente è necessaria in molti scenari, prima di tutto vi permette di validare le procedure di upgrade, in questo caso create un clone del vostro TFS, eseguite le procedure di upgrade sul clone e poi con tutta calma potete verificare che dopo l’upgrade tutto funzioni correttamente.

Un altro scenario tipico è lo sviluppo di estensioni per TFS, perchè con un ambiente Clonato potete sviluppare e testare i vostri plugin o il vostro software su un clone esatto dei dati di produzione, senza interagire con il server di Produzione.

Potete leggere il post integrale nel mio blog inglese che trovate a questo indirizzo, nel quale ho aggiunto anche altri semplici consigli per minimizzare il rischio che l’ambiente Clonato possa interagire con l’ambiente di Produzione generando confusione e problemi.

Gian Maria.

Agile, Lean and DevOps… a common definition

To answer at the classic question “…. ok, but what is Agile? and Lean… ah, yes… also DevOps?!?” what do you think about this definition?

Agile, Lean and DevOps are a set of Values, Principles and Practices, focused on people, and supported by tools and automatisms, that help the whole company to achieve the best values from it’s business initiative, working in an efficacy and efficient way.

 

Nuovo update di VSTS–7 luglio

Un altro sprint è stato deployato in Visual Studio Team Services il 7 luglio e dovrebbe ora essere disponibile per tutti gli account. Come sempre il team ha pubblicato un post con tutte le novità, ed in questo sprint sono state fatte molte modifiche alla ui ed alla usabilità.

Un aspetto interessante è l’inclusione del code coverage dei test eseguiti durante la build, metrica interessante per tutti i team che fanno uso estensivo di unit testing.

Tutte le restanti modifiche sono relativamente piccoli miglioramenti e potete quindi leggerli nel post originale.

Gian Maria.

DA2, Disciplined DevOps strategies

Parlando nel precedente post di Data Management abbiamo implicitamente aperto la finestra su quelle che sono le strategie associate ad un “approccio disciplinato” a DevOps.

Come descritto nel primo post dedicato a Disciplined DevOps, un approccio maturo a DevOps prevede il coinvolgimento di 6 aree aziendali

full disciplined devops

ognuna custode di parte degli aspetti complessivi dell’azione di Deployment che, lo ricordiamo, e’ l’atto finale grazie al quale gli utenti possono effettivamente utilizzare la nuova soluzione.

Ognuna di queste aree, non obbligatoriamente presenti in modo esplicito all’interno di una organizzazione, ha una serie di specifiche esigenze che DA2 raccomanda di bilanciare tra loro attraverso la scelta di opportune strategie ad esse annesse: 

  • Development Strategies, incentrate sulle diverse pratiche che consento al development di supportare al meglio le attività di Delivery. Si spazia, quindi, dagli aspetti di testing a quelli di Continuous Integrarion/Delivery/Deployment;
  • Operations Strategies, incentrate sulle diverse pratiche che consento a operations di supportare al meglio le attività di Delivery: si pensi all’automazione del provisioning degli ambienti o al monitor delle applicazioni;
  • Support (Help Desk) Strategies, focalizzate sugli aspetti di supporto applicativo. Si va dalle classiche FAQ alla capacità delle applicazioni stesse, grazie ad appositi tool di monitoring, di segnalare prontamente al team e agli utenti eventuali problemi;
  • Release Management Strategies, incentrate sulle strategie di Release che, come decritto in un primo post di approfondimento, possono prevedere una funzione esplicita o essere demandate al team;
  • Data Management Strategies, con focus su una gestione disciplinata dei dati. Si veda il post precedente per i dettagli;
  • Enterprise Architecture Strategies, in cui vengono proposte delle possibili strategie per la creazione e gestione di una efficiente ed efficace architettura IT di riferimento a livello aziendale.

In aggiunta, DA2 prende in considerazione un’ulteriore set di aspetti trasversali, raccolti sotto il cappello General e Teaming Strategies. General, in particolare, si occupano di definire le strategie complessive di un approccio Disciplined DevOps: troviamo così una particolare enfasi, ad esempio, sugli aspetti collaborativi e sull’importanza dell’automazione dei processi. Teaming si focalizzata sulle possibili strategie di integrazione delle attività, e quindi di team, con particolare attenzione ai Dev e agli Ops.

Tutte le aree, quindi, sono caratterizzate da specifiche strategie che vengono definite “DevOps-friendly” e supportano diversi livelli di adozione, bilanciando il rischio di adozione, l’effort di adozione e i risultati attesi.

Nei prossimi post andremo a vedere nello specifico le diverse strategie che caratterizza le aree fondanti di Disciplined DevOps, in modo da completare quanto iniziato con la descrizione delle strategie di Data Management.

 

Stay tuned!

DA2, Data Management

L’azione di Delivery enfatizza quasi sempre un’attenzione estremamente spostata sul codice (Build), relegando gli aspetti afferenti al mondo dei Dati in posizione secondaria, quasi accessoria.
Eppure l’organizzazione, la gestione e la persistenza dei dati e’ fondamentale, essendo aspetti che appartengono alla sfera dell’Enterprise Architecture, ossia dell’architettura informativa a supporto del business. Il motivo è presto detto: un’accesso efficiente ed efficace ad essi, in funzione delle diverse aree e dei diversi servizi in esercizio, consente di avere prontezza della validità delle diverse assunzioni strategiche effettuate, sia di business che organizzative.

da2 disciplined devops

DA2 evidenzia tutto ciò in modo esplicito, prevedendo la pratica di Data Management e specializzandola su tre azioni primarie:

  • Data and Information guidelines: si tratta di avere una serie di linee guida da seguire nella creazione, nell’accesso e nella gestione dei differenti dataset. Tutto ciò va automatizzato il più possibile in modo da ridurre inefficienze e problemi. Si pensi, solo per citare un esempio classico, alle policy di backup;
  • Quality data source: la continua richiesta di cambiamento nei sistemi, dettati dalle nuove esigenze dei clienti e del mercato, si riflette in modo diretto anche sulla strutturazione dei dati e dei relativi repository. Per poter supportare il tutto in modo efficace e’ necessario che i dataset siano facilmente aggiornabili ed evolvibili, ostacolando la tentazione di creare continui workaround per supportare le nuove richieste. I workaround producono rapidamente un aumento esponenziale del Debito Tecnico, rendendo la soluzione ingestibile nel medio-lungo periodo;
  • IT intelligence: dati di qualità consento di poter effettuare tutta una serie di analisi trasversali, spesso grazie al supporto di strumenti di BI che permettono di analizzare l’andamento del proprio business. Ma l’IT intelligence sposta questo focus sull’analisi di quello che è l’improvement della propria divisione IT, mettendo a fattor comune i dati derivanti dai tool per la gestione integrata di una valida e robusta azione ALM. Si pensi, solo per fare un esempio estremamente semplice, alla possibilità di visualizzare il numero di Build di successo man man che il team prende confidenza l’Agile, in modo da poterne rafforzare l’azione laddove si dovessero verificare problemi di qualità. Queste informazioni sono utilizzabili, con diversi livelli di aggregazione, dai singoli team fino al Middle-management, in modo da allineare l’intera organizzazione sullo stato corrente. Più di rado gli aspetti tecnici possono interessare in modo diretto il Portfolio Level, anche se essi possono essere correlati con altre informazioni per creare indicatori relativi, ad esempio, al time-to-market o alla produttività.

Risulta estremamente evidente come i dati rappresentino una variabile fondamentale nel nostro processo DevOps, consentendo di creare opportune metriche di valutazione. In questo scenario, l’utilizzo di una piattaforma relativa integrata, come Visual Studio Team Services, permette di relazionare le varie informazioni in funzione delle diverse fasi di Delivery, evidenziando colli di bottiglia e, di conseguenza, aspetti su cui intervenire rapidamente per ridurre gli sprechi annessi al processo.

VSTS Month – Evento Online

In occasione del VSTS Month, su cui potete leggere maggiori dettagli in questo post su MSDN, GetLatestVersion ha deciso di partecipare all’iniziativa con un evento online.

Dato che GLV non è localizzata in nessuna precisa area geografica italiana, e soprattutto dato il grande numero di eventi community che ci sono negli ultimi anni, abbiamo pensato che il formato Online potesse essere sicuramente il migliore. In questo modo tutti possono partecipare, non è necessario spostarsi e registreremo direttamente l’evento in modo da pubblicarlo poi online.

Se volete iscrivervi, potete farlo su EventBrite, l’evento si terrà il 19 Luglio nella fascia oraria 18:00 / 19:30 e sarà organizzato in due tempi. Nel primo, della durata approssimativa di Mezzora / Tre quarty presenteremo Visual Studio Team Services, facendo una panoramica sulle funzionalità. Nel secondo tempo avrete modo di chiedere approfondimenti su qualsiasi cosa vi interessi, una sorta di AMA (Ask Me Anything).

Se il formato online piace, possiamo pensare di fare ulteriori eventi in futuro, magari verticalizzati su alcune parti di VSTS / TFS oppure coprendo scenari End-To-End.

Vi aspettiamo.

Il Team Di GetLatestVersion.

0  

Priorizzare il proprio lavoro: Time Management Matrix

Tutti gli approcci Agile/Lean based spostano il focus dalle fasi al bouquet di funzionalità da realizzare per soddisfare un’esigenza del cliente. Ciò si traduce praticamente in un Product Backlog che contiene i work item su cui concentrare le nostre attività.

Tali work item vanno ordinati (priorizzati) per Valore… ma qui sorge una domanda fondamentale: “cos’è il Valore nel nostro contesto?”.

Il desiderata dell’utente? Una iniziativa mirata a ridurre il rischio per il progetto? Una serie di storie pensate per chiarire gli aspetti UX/UI?

Tutte queste declinazioni sono una valida interpretazione del concetto di Valore, per cui può diventare estremamente difficile ordinare il nostro backlog, visto che le variabili in gioco potrebbero aumentare in modo considerevole.

Un interessante framework che può essere utilizzato per dare una prima connotazione di Valore ai nostri work item è rappresentato dal Time Management Matrix (TMM) di Stephen Coveys, a sua volta formalizzazione di un sistema di supporto strategico utilizzato dal generale Dwight D. Eisenhower, successivamente presidente degli USA.

tmm 1

Time Management Matrix

Lo scopo è quello di inquadrare le attività in funzione di due assi di rilevanza specifica: Urgenza e Importanza. Questa scelta è decisamente ovvia, se si pensa che spesso, ogni richiesta del business è Urgente ed Importante allo stesso modo, e il tentativo è quello di porre sempre le nuove attività in cima a quelle in essere, andando a causare una saturazione di gestire efficacemente il loro completamento. Questo perché, spesso, si discute in termini di capacità (Capacity) totale del team e non di un efficace gestione del flusso (Throughput) operativo.

L’esempio classico per spiegare questa differenza è dato dalla similitudine con l’autostrada:

road capacity throughput

se la richiesta è inferiore alla capacità, allora le autovetture hanno lo spazio (slack) per avere un flusso sostenibile senza creare traffico. Viceversa, se la richiesta è uguale o addirittura maggiore alla capacità viaria, le autovetture resteranno incolonnate causando una congestione del traffico.

La TMM è uno strumento che consente di inquadrare i diversi work item in quattro fasce specifiche:

  • Urgente e Importante, sono i task più rilevanti nel breve periodo;
  • Importante ma non Urgente, sono i task più rilevanti nel medio-lungo periodo;
  • Urgente ma non Importante, sono i task che vanno fatti ma possono essere delegati;
  • Non Urgente e non Importante, sono i task da eliminare.

 

tmm 2

TMM Actions

Se da un punto di vista operativo, il primo quadrante cattura subito la nostra attenzione, il secondo quadrante è invece quello strategico, poiché contiene i task più importanti per la continuità del nostro business.

In pratica il primo quadrante è riconducibile all’Iteration/Sprint backlog, mentre il secondo appartiene a quello che è il Program Backlog e il Product Backlog, che trasformano le iniziative di business in azioni concrete.

Chiaramente il focus di interesse è proprio sul secondo quadrante, in quanto gestendo opportunamente le relative attività è possibile evitare che esse si spostino al primo trasformandosi in “urgenze” che vanno a minare la stabilità e il ritmo di lavoro raggiunto.

Il terzo e quarto rappresentano genericamente uno spreco da ridurre (terzo) e da eliminare (quarto). Le relative attività vanno però tenute in costante considerazione perché incidono sulla pianificazione generale. Facciamo un esempio: se non si riesce a sfoltirli, parte della giornata lavorativa, anche se minima, sarà chiaramente dedicata ad essi, per cui non sarà possibile stimare il tempo di una iterazione basandosi sulle canoniche 8ore lavorative, ma bisognerà ragionare sulle 7ore, o ancora meno, in cui effettivamente ci si dedica ai work item del primo e del secondo quadrante.

La difficoltà intrinseca di questo framework è, chiaramente, quella di riuscire a distinguere tra urgenza e importanza e, come tutte le cose, il miglior modo per affinare le proprie capacità è quello di esplorare e procedere sul campo.

Stay tuned!

Aggiornamento VSTS del 17 giugno

Questa volta l’aggiornamento è stato più rapido del previsto, il 17 giugno abbiamo avuto un altra wave di aggiornamenti su Visual Studio Team Service. Come sempre potete leggere tutti i dettagli nel blog ufficiale, qui vi farò un riassunto delle mie nuove funzionalità preferite.

Innanzitutto se avete un team corposo ed usate GitFlow è possibile che il numero delle branch in Git diventi elevato, per questo nel tab delle branches è ora disponibile una sezione “my branches” dove vedrete le branch che avete creato voi o a cui avete contribuito. In questo modo è immediato distinguere le vostre branch da quelle di altri componenti del team.

Branch picker featuring Mine

Un’altra importante novità è un nuovo header per la form dei Work Item, in particolare è ora presente in molta evidenza il bottone “Save & Close” che sicuramente è quello più utilizzato, dato che molto spesso dopo che si apre un Work Item se lo si modifica si vuole semplicemente chiudere salvando le modifiche effettuate.

Improved work item header

Per tutti coloro che usano le funzionalità di Test ed in particolare le exploratory sessions, è ora finalmente possibile avere una visualizzazione chiara di tutte le exploratory session effettuate sul progetto.

Insights in exploratory testing

Nell’addin di Chrome è ora possibile anche richiedere la registrazione del desktop da includere in un eventuale bug.

Un’altra interessantissima funzionalità è la possibilità di vedere l’andamento dei test per singole branch, questo è molto importante perché cosi si ha la chiara indicazione della qualità delle varie branch

History tab in the result summary page

La funzionalità sicuramente più corposa è però data dalla possibilità di personalizzare il Process Template introducendo stati custom. Questa funzionalità ha un intero post dedicato all’argomento, e costituisce un ulteriore importante passo verso la parità di funzionalità tra VSTS e TFS. Questo permette quindi di avere colonne personalizzabili nella Task Board, grazie alla possibilità di aggiungere stati al Work Item di tipo Task. Non è ancora possibile personalizzare in maniera avanzata le transizioni tra stati (con regole o decidere quali transizioni sono possibili), ma già questa funzionalità rende possibile personalizzare VSTS in modo che si adatti maggiormente alle vostre esigenze.

Per chi sviluppa Java invece è ora possibile effettuare analisi di codice direttamente da un task Maven, senza la necessità di impostare un server Sonar Qube, anche questa funzionalità è abbastanza corposa e descritta in dettaglio in un post dedicato.

Vi invito comunque a leggere il post ufficiale in modo da vedere tutte le novità disponibili.

Gian Maria.

AgileIoT Kanban::Board: il workshop a BetterSoftware

Lunedì ho avuto il grande piacere di partecipare nuovamente come speaker a BetterSoftware, che quest’anno si è presentato al pubblico, sempre numeroso e competente, nel nuovo format “workshop based”.

Come accennato nel post precedente, il mio workshop puntava a far toccare con mano la Kanban::Board di AgileIoT, evidenziando l’efficacia del WorkPivot e del D-ARCH.

Ebbene,  i 4 team pratecipanti (da 5 e 6 persone) si sono divertiti nel:

“realizzare un sistema intelligente di pubblicità da posizionare su strutture di piccole dimensioni come, ad esempio, le statue. Il messaggio doveva essere visibile dalle diverse angolazioni ed illuminato adeguatamente, gestendo in modo efficiente l’aspetto energetico al fine di consentire un abbattimento dei costi e consentire l’installazione in aree anche senza fornitura elettrica.”

Ovviamente non sono stati utilizzati dei veri EVK e laptop, ma la prototipazione è avvenuta tramite una “torcia a mano” di origine cinese, mentre alla consegna del BOM, l’external PO Manufactoring forniva una torcia decisamente più industriale.

Particolare attenzione è stata posta nel tracciare il lavoro attraverso la Kanban::Board, evidenziando anche i disallineamenti tra lo stato reale del lavoro e quanto evidenziato visivamente, con tutti i problemi derivanti.

In particolare un team aveva praticamente terminato tutta la componente Software/Firmware e Cloud, mentre la parte hardware era bloccata: questa situazione può spingere, ad esempio, ad intervenire sul know-how in ambito hardware, avendo ottenuto come risposta “non siamo in grado di rimontare la torcia”.

Un workshop ricco di spunti per i quali i ringraziamenti vanno ovviamente ai partecipanti che si sono sbizzariti, soprattutto nel creare la struttura di supporto all’ADV, come potete vedere dalle foto seguenti. Un ulteriore e doveroso ringraziamento agli amici di BetterSoftware per l’alto livello dell’evento e l’ottima organizzazione.

Al prossimo anno!

2016 bsw16 agileiot workshop 1 2016 bsw16 agileiot workshop 2

2016 bsw16 agileiot workshop 3 2016 bsw16 agileiot workshop 4

2016 bsw16 agileiot workshop 5 2016 bsw16 agileiot workshop 6

2016 bsw16 agileiot workshop 7

Potete trovare le slide del workshop qui: http://www.slideshare.net/felicepescatore/advtorch-agileiot-bettersoftware-2016-workshop

Stay tuned!