Category Archives: ALM

Application Lifecycle Management

DevOps e l’ecosistema Microsoft, parte 4: Release

Completato lo sviluppo del codice e dei test di unità annessi alla specifica Storia (ovviamente gli unit test devono essere “green”, ossia superati ;-)), la build intraprendere il suo viaggio verso i sistemi di produzione attraversando una serie di ambienti (environment) atti a comprovarne specifici aspetti funzionali e qualitativi.

ms devops 3

Release

Si entra così nel mondo della Continuous Delivery (e Continuous Deployment se si arriva fino in produzione), le cui azioni interessano almeno quattro ambienti primari: quello per i test funzionali (o di accettazione), quello per i test di integrazione e security, quello per gli stress test e l’ambiente di produzione stesso. È importante evidenziare come per test di integrazione si intendano i test dell’integrazione con gli ambienti e i servizi terzi a supporto (come l’istanza del DB in produzione, i servizi di piattaforma, ecc) che prima erano stati sostituiti con dei mock-up per consentire di concentrarsi sulla verifica esclusiva della soluzione in sé, senza che la stessa fosse condizionata da fattori esterni. I test di integrazione del codice sviluppato sono, come abbiamo visto, eseguiti nel processo di Continuous Integration.

ms devops 3b

Continuous Delivery

Lo strumento principe per gestire tali aspetti in VSTS è Release, il cui cuore operativo è rappresentato dalla Release Definiton che consente di impostare le azioni annesse ad ogni singolo ambiente coinvolto nel processo di rilascio della nuova build.

vsts release

Release

Idealmente, gli ambienti possono essere visti come Work Center (Lean Manufactoring) da attraversare per far si che la build divenga “ready to release” e possa essere dispiegata (più o meno in modo automatizzato) sugli ambienti di produzione.

vsts release environments

Gestione degli Ambienti e dei Task di delivery

È fondamentale sottolineare come il provisioning (attivazione) degli ambienti dovrebbe avviene il più possibile in modo automatizzato, sfruttando l’approccio Infrastructure as a Service. Questo perché l’obiettivo da perseguire è quello di rendere del tutto autonomi i dev nella creazione/distruzione degli ambienti di test, mentre gli ops si occupano della gestione dell’infrastruttura e dei tool a supporto, oltre a scrivere a due mani, proprio con i dev, i diversi script afferenti. Tra le soluzioni relative “made in Redmond” troviamo Azure Release Management (ARM), che consente di attivare risorse “on-demand” sul cloud Azure.

Con ARM la configurazione dell’infrastruttura a supporto avviene attraverso script che sfruttano la notazione JSON, andando a creare un vero e proprio “artefatto” il cui ciclo di vita può essere gestito esattamente come avviene per il codice sorgente della soluzione in sviluppo.

azure rm template lifecycle 1

azure rm template lifecycle 2

IaaS Lifecycle

Una vota creato lo script ARM, per eseguirlo è possibile inserire nella gestione di Release lo specifico task, andando ad attivare le risorse in esso descritte sulla specifica sottoscrizione Azure.

vsts arm task

ARM tasks

Il dispiegamento sull’ambiente di verifica funzionale è fondamentale per consentire l’esecuzione degli User Acceptance Test (UAT) da parte del team di Quality Assurance (o del team stesso di sviluppo se il progetto è di piccole dimensioni e lavora, ad esempio, in Scrum) ma, soprattutto, da parte dell’utente finale, che può fornire feedback preziosi. Tale ambiente è quello che può, ad esempio, essere sfruttato durante l’Iteration/Sprint Review, e lasciato poi a disposizione dell’utente finale per test e feedback successivi, se non si decide di andare subito in produzione.

In particolare, è possibile invitare gli utenti a verificare specifici elementi della soluzione tramite una richiesta esplicita di feedback.

vsts feedback 1 vsts feedback 2

Feedback request

Inviata la richiesta, l’utente riceve una mail con tutte le istruzioni per avviare (o installare se non presente) Microsoft Feedback client che permette di seguire le diverse fasi di verifica fino all’invio delle osservazioni in merito.

vsts feedback 4

Feedback

Successivamente, i feedback ricevuti possono essere visualizzati dal team di delivery tramite una semplice query, creando anche elementi personalizzati sulla dashboard per evidenziarne aspetti particolari.

vsts feedback 5

Feedback Query

Lato Quality Assurance il processo può essere proficuamente gestito attraverso appositi Test Plan, andando a definire passo passo tutte le verifiche da effettuare e raccogliendo strutturalmente i risultati.

vsts test plan

Test Plans

vsts test plan execution

 Esecuzione di un Test Plan

Se l’environment di riferimento è quello dedicato ai test di carico, ovvero alla verifica dell’affidabilità dei servizi in condizioni di carico specifico o particolare, il test stesso potrà essere configurato sfruttando gli appositi task che consentono di gestire questa tipologia di validazioni e catturarne l’esito.

vsts web test

Quick Web Performance Test LoadTest

Si tratta di un’azione molto simile a quanto realizzato con i progetti Web Performance and Load Test di Visual Studio IDE, andando però a sfruttare le risorse Cloud per simulare in modo più realistico un utilizzo intensivo dei servizi.

Release si presta a numerose personalizzazioni ed estensioni, tra cui Octopus Deploy e, il già discusso, LaunchDarkly [rollout]. Octopus Deploy è una piattaforma di Continuous Delivery/Deployment che si integra con VSTS in modo da diventare “un’appendice” dell’azione di Continuous Integration e sostituire la parte proprietaria di Release. Octopus si è ritagliato un’interessante spazio nel mondo DevOps Microsoft-related, anche se l’integrazione diretta di Release in VSTS/TFS (precedentemente Release Management era un tool a parte) ha reso disponibili nativamente molte delle sue caratteristiche.

Tornando invece a LaunchDarkly, i relativi task di rollout (da collegare alla definizione degli step di delivery sui vari ambienti) consentono di gestire proprio l’azione di rollout, ovvero bilanciare il numero di utenti che avranno accesso alle nuove funzionalità.

extension launch darkly 2

LaunchDarkly rollout work item

extension launch darkly 3 rollout

LaunchDarkly rollout release task

La build, una volta validata ed avviato il processo di rollout, verrà dispiegata in produzione e, da quel momento in poi, sarà necessario attivare una serie di servizi e strumenti di supporto e monitoraggio applicativo.

Questo sarà l’argomento del prossimo post in cui approfondiremo l’area di Monitor and Learn e vedremo come essa produca un output che, a sua volta, diventa uno degli elementi di input per la nuova fase di Planning.

 

Post precedenti della serie:

DevOps e l’ecosistema Microsoft, parte 3: Develop and Test

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.

ms devops 2

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:

vsts iterations

 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.

vsts board sprint

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.

extention easy estimation

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.

vsts diagram cfd

Cumulative Flow Diagram (CFD)

vsts diagram burndown

Iteration/Sprint Burndown

vsts diagram velocity

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.

vs unit testing

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.

vsts pull request

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.

vsts build definition

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.

vsts ci

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.

ms devops 2b

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.

extension sonarqube build integration

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.

others ab testing

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.

extension launch darkly 1

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 planner

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 teams

 Office 365 Teams

 

Post precedenti della serie:

DevOps e l’ecosistema Microsoft, parte 2: Agile Planning

Continuiamo il nostro viaggio alla scoperta di DevOps attraverso l’ecosistema Microsoft (qui la prima parte).

ms devops 1

Ogni nuova idea, prima di poter diventare un prodotto ed avere allocate le risorse per realizzarlo, deve necessariamente passare per la relativa validazione di sostenibilità (spesso indicata come Inception) analizzandone i contorni, valutandone i rischi e le relative opportunità di mercato.

In generale, per la prima fase di approfondimento si preferisce usare i cosiddetti Canvas, ovvero una serie di panel che permettono di esplicitare i diversi elementi strategici che andranno a caratterizzare l’azione di mercato del nuovo prodotto, oltre alle caratteristiche del prodotto stesso.

canvas

Canvas

I Canvas più noti sono: Vision Board Canvas, Business Model Canvas/Lean Canvas e Product Canvas che, nell’ordine esplicitato, vanno dalla visione annessa al nostro prodotto fino a quello che è una sorta di primo draft con i diversi elementi specifici.

Allo stato attuale, VSTS non offre un supporto diretto ai Canvas, per cui può essere utile sfruttare servizi terzi come Canvanizer per rappresentarli in modo digitale e collegarli tramite link a specifiche Epic del prodotto.

canvas canvanizer

 Canvanizer

Resta, chiaramente, sempre valida l’opzione di usare dei panel materiali (stampe) dei Canvas, fotografarli e gestirli tramite il repository documentale associato al prodotto, ad esempio SharePoint. In particolare, tramite il Product Canvas si vanno ad esplicitare diversi elementi di liftoff gestiti direttamente da VSTS:

  • Name, il nome del prodotto;
  • Goal, gli obiettivi;
  • Metrics, il modo in cui il raggiungimento dei goal viene misurato;
  • Target Group, le Personas che lo utilizzeranno;
  • Big Picture, gli elementi fondamentali che descrivono il prodotto: Scenari, Mock-up, StoryBoard, ecc.;
  • Product Details, gli item da realizzare: epic, feature, user story (anche se più di rado).

canvas product

The Product Canvas

Come accennato, tali elementi sono effettivamente “mappati” e rappresentati direttamente in VSTS:

  • Name, è il nome stesso del Team Project;
  • Goal, è possibile utilizzare delle estensioni del Marketplace come “Product Vision” per esplicitarli nella Dashboard;
  • Metrics, utilizzando l’estensione di “Application Insight” si può visualizzare una tile con le informazioni rilevanti direttamente nella dashboard;
  • Target Group, è possibile sfruttare l’estensione del marketplace “Personas”.

Big Picture e Product Details necessitano di un maggiore approfondimento.

Partiamo da Big Picture. Qui si sfruttano strumenti come le StoryBoard di PowerPoint per produrre i mock-up del prodotto, consentendo al potenziale utente (Personas) di navigare le diverse schermante e fornire feedback agli sviluppatori in modo che possano essere allineati con le sue aspettative.

Una volta realizzato il mock-up, si potrà collegarlo direttamente ad un Product Backlog Item (PBI) e gestirlo come elemento di dettaglio della relativa realizzazione direttamente da VSTS.

office powerpoint storyboard

Story Board con Power Point

La sezione del Canvas “Product Details” si trasforma negli elementi di Planning tipici del mondo Agile, vale a dire Epic/Feature/User Story, che VSTS utilizza in modo intensivo per consentire di coordinare le attività di realizzazione del prodotto.

vsts agile items

VSTS Agile Items

I diversi item possono essere personalizzati ed estesi, e ne possono esserne creati di nuovi per adattare al meglio VSTS alle proprie esigenze. In generale, il consiglio è sempre quello di cercare di sfruttare al massimo quanto offerto di default con lo specifico process template e solo se veramente indispensabile effettuare specifiche personalizzazioni. Ciò riduce il rischio che futuri aggiornamenti possano invalidare quanto personalizzato o non funzionare correttamente.

A livello management gli item afferenti al IT Portfolio Management, ovvero le Epic e le Feature, vanno a definire le iniziative annesse al singolo prodotto e sono gestiti principalmente attraverso specifiche Kanban Board.

vsts board epic

Epic Kanban Board

 

vsts board feature

Feature Kanban Board

Le Kanban possono essere completamente personalizzate, consentendo di aggiungere, ad esempio, la specifica Definition of Done per singola colonna e il relativo Work in Progress Limit.

vsts board kanban personalize

 Personalizzazione della Kanban Board

Sia le Epic che le Feature dispongono di specifici dettagli che consentono di caratterizzarli in funzione sia degli obiettivi di Business che delle esigenze tecnico/tecnologiche. Non andremo ad analizzare i dettagli nello specifico perché ciò richiederebbe una trattazione specifica che esula dallo scopo dell’approfondimento in corso. Inoltre, molte informazioni a riguardo, sono presenti nell’ottima documentazione ufficiale a riguardo [Backlog and Work Items].

vsts epic details

Epic Details

Fondamentale, invece, è sottolineare come VSTS (in chiave Agile) sposi l’organizzazione a Feature Teams, dove i membri del team stesso possono organizzare e gestire il proprio (Team) Backlog, composto primariamente da Story, Task e Bug.

vsts board team

Team Backlog

Anche in questo caso la gestione tramite Kanban consente di sfruttare al meglio la logica di Visual Management e avere sempre una fotografia aggiornata dello stato di avanzamento delle attività.

Per chi preferisce utilizzare una Kanban/Scrum Board “fisica” e vuole evitare di dover lavorare su entrambe, aggiornandole di conseguenza, può sfruttare una utile estensione del marketplace chiamata Agile Cards.

extension agilecard

Agile Cards

Una volta definiti i Product Backlog Item (PBI) è possibile stampare le relative card, utilizzarle su una Kanban/Scrum Board “fisica”, fotografarne i cambiamenti e lasciare che VSTS si aggiorni di conseguenza! La “magia” avviene tramite una serie di “tag” posti su ogni singola card.

Nel caso il prodotto contempli più progetti e, quindi, più team specifici, il relativo lavoro può essere organizzato in modo che gli stessi abbiano in comune il Product Backlog ma al contempo lavorino su specifici Team Backlog correlati ad esso. Qui si entra nel campo dell’Agile Scaling dove troviamo framework metodologici come: Scaled Agile Framework (SAFe), Disciplined Agile 2 (DA 2) e LeSS.

others multi team

Agile Scaling

Per adattare VSYS a questo scenario, è necessario creare più Feature Team ed associare ad ognuno di essi specifiche Work Area (derivate da quella base del progetto). In tal modo gli item identificati durante planning, in funzione a specifici goal, potranno essere associati ai diversi team coinvolti in modo esclusivo.

vsts feature team

Multi Feature Team

Le attività di sviluppo dei diversi team afferenti allo stesso prodotto possono essere visualizzate e ottimizzate tramite l’estensione Delivery Plans, consentendo di avere un quadro a livello Program, così come inteso dal framework Scaled Agile Framework.

extension plans

Delivery Plans

All’interno dei Project Template Agili (ovvero dei modelli di processo predefiniti, uno generico per Agile e uno più specifico di Scrum) oltre agli item di sviluppo evolutivo visti fin ora, sono presenti anche il già citato Bug e l’item di Impediment, che rappresenta un problema bloccante e come tale, ovviamente, non viene riportato nel Product Backlog non essendo un elemento di pianificazione. Entrambi sono estremamente importanti per consentire al team di attivare azioni di miglioramento, potendo, ad esempio, misurare il numero di problemi in ogni increment o i diversi impedimenti che si riscontrano durante le attività giornaliere. In particolare, è utile applicare la regola dell’80/20 (validata in modo empirico) che spinge il team a dedicare il 20% del proprio tempo a ottimizzare quanto realizzato, riducendo costantemente il Debito Tecnico.

Prima di chiudere la trattazione dell’area Agile Planning, è utile evidenziare che la pianificazione avviene al livello minimo indispensabile per dare il là alle prossime attività di sviluppo, in perfetto stile Agile/Lean. Questo perché la stessa viene rivista, approfondita ed estesa ad ogni iterazione o al raggiungimento dei goal specificamente settati per le attività in corso.

 

Nel prossimo appuntamento ci concentreremo sull’area Develop & Test, andando a vedere come VSTS e VS IDE supportano egregiamente le attività operative di realizzazione concreta della soluzione.

 

Stay tuned :-)

DevOps e l’ecosistema Microsoft, parte 1: intro

DevOps è diventato nel giro di pochi anni uno dei principali approcci con cui le organizzazioni affrontano la realizzazione di soluzioni IT al servizio del Business. Questo perché, effettivamente, la sua adozione profonda, organizzativa e tecnico/tecnologica, consente di ottimizzare i processi di delivery di soluzioni con reale Valore per il cliente, andando ad utilizzare al meglio le Persone e le risorse a disposizione.

Da questo blog abbiamo affrontato più volte la tematica primariamente da un punto di vista metodologico, evidenziando come DevOps sia prima di tutto un cambiamento Culturale basato su cinque pillar fondamentali: Comunicazione, Integrazione, Collaborazione, Automazione e Misurazione.

Proviamo, ora, a fare un viaggio attraverso l’ecosistema che Microsoft mette a disposizione di quanti vogliano intraprendere una trasformazione in chiave DevOps, utilizzando soluzioni flessibili, moderne ed integrate che consentono di attraversare tutte le fasi organizzativi ed operative annesse ad una nuova iniziativa IT.

ms devops philosophy full

 Microsoft DevOps Philosophy

Le quattro aree in cui ci si muoverà possono essere così specializzate:

  • Agile Planning: tutto inizia con una idea… e un piano per trasformarla in realtà.

    • Inizio, vengono effettuate le attività necessarie a validare la sostenibilità dell’iniziativa;
    • Pianificazione, viene creato un project charter di riferimento;
    • Gestire il lavoro, vengono adottate le diverse metodologie e pratiche operative;
    • Tracciare i progressi, viene misurato l’avanzamento del progetto ed i miglioramenti ottenuti nelle diverse aree.
  • Develop and Test: una volta che le iterazioni sono partite, i team agili si occupano di trasformare grandi idee in funzionalità.
    • Scrittura del codice, il codice viene scritto dai dev;
    • Unit Test, gli stessi dev realizzano i test relativi al proprio codice;
    • Version Control, una vota completata la scrittura ed una prima validazione, tutto il codice viene salvato nel Version Control System del prodotto;
    • Build, il codice viene integrato in un’ottica di Continuous Integration e quindi viene scatenata la build del nuovo Increment (tutto il codice scritto fino a quel momento);
    • Verifica delle Build, il processo di Continuous Integration si completa con l’esecuzione automatizzata dei test annessi.
  • Release: quando tutti i test annessi alla build sono superati, la stessa comincia ad essere dispiegata sui diversi ambienti previsti dal processo di release per le validazioni successive.
    • Ambiente per i test funzionali, l’Increment viene valutato in funzione della sua aderenza ai requisiti funzionali (User Acceptance Test);
    • Ambiente per i test di integrazione e security, qui l’artefatto viene integrato con tutti gli elementi “esterni”, viene validata l’integrazione, così come gli aspetti di security;
    • Ambiente di pre-produzione per stress test, l’Increment è sottoposto a tutta una serie di stress-test per validarne l’affidabilità e la risposta in condizioni di funzionamento non ottimali o inattese;
    • Ambiente di produzione, l’Increment diventa la nuova release del nostro prodotto che viene rilasciata in produzione.
  • Monitor e Learn: una volta in produzione, l’applicazione viene costantemente monitorata in modo da ottenere preziose informazioni di allineamento e miglioramento.
    • Monitoraggio, la soluzione in erogazione viene costantemente monitorata, tramite appositi tool di instrumentazione, al fine di ottenere informazioni costanti sul suo funzionamento;
    • Feedback, tutte le informazioni di funzionamento, insieme a quelle esplicite degli utenti, vengono raccolte e diventano un elemento portante per il planning delle successive attività.

Lo scopo è quello di favorire il flusso costante (flow, 1° principio di DevOps) del lavoro lungo tutta la pipeline di delivery andando ad individuare quanto prima, e possibilmente in modo automatizzato, i problemi, trasformandoli in feedback (feedback, 2° principio di DevOps) e consento al team di prodotto di migliorare costantemente l’intero processo (learn and experimentation, 3° principio di DevOps).

Fondamentale è la pratica di conferire a tutti i membri operativi del team, nessuno escluso, la possibilità di “interrompere” le attività in corso per risolvere qualsiasi problema si verifichi sulla pipeline stessa, esattamente come avviene per TPS (Toyota Production System) /Lean con l’Andon cord.

 andon cord

Andon cord

Questo approccio è fondamentale per identificare i problemi il più vicino possibile alla fonte, ed evitare che si sommino e propaghino lungo la pipeline andando ad aumentare il Debito Tecnico.

Nei prossimi post andremo ad affrontare in dettaglio ognuno di questi macro aspetti, in relazione a Visual Studio Team Services (o TFS), Office 365, Visual Studio, e le altre soluzioni del mondo Microsoft, evidenziando come sia possibile integrarli con soluzioni terze laddove sia necessario estenderne le funzionalità o coprire aree attualmente non contemplate.

L’obiettivo è quello di dare una visione lineare su come l’ecosistema di Redmond sia in grado di supportare le necessità di chi decide di abbracciare il paradigma DevOps, sia nelle pratiche metodologiche che negli aspetti tecnici/tecnologici.

Non entreremo, quindi, nel dettaglio delle singole funzionalità offerte dai differenti tool, né, tantomeno, li riporteremo necessariamente tutti in modo esplicito, lasciando al lettore la scelta di approfondire ciò che ritiene opportuno tramite l’ottima documentazione e i blog tematici disponibili online.

 

Per ora è tutto, ci aggiorniamo al prossimo post.. stay tuned :-)

#noelevator

Ask Me Anything n. 17/2

Ricorre l’appuntamento a microfono aperto. Gli esperti della community GetLatestVersion sono a vostra disposizione proporre domande su qualunque tema attinente a Application Lifecycle Management, Ciclo di vita del Software e DevOps. Non ci sarà una scaletta od una impostazione predefinita, e le risposte possono essere anche supportate da demo immediate o approfondimenti provenienti da esperienze […]

Comments Off on Ask Me Anything n. 17/2  

SecOps, DevSecOps, SecDevOps… la sicurezza al centro dell’azione di delivery

Per fortuna che esistono gli acronimi! Senza di essi che mondo sarebbe!! (ok, mi sono ispirato ad una famosa pubblicità nostrana :-))

Senza acronimi, però, il mondo dell’IT sembrerebbe in stallo perenne e alcuni temi portanti finirebbero pericolosamente nel dimenticatoio, sopraffatti dalla moda del momento.

In questo caso la domanda è banale: ma serve creare un nuovo acronimo per ricordarci ancora oggi che gli aspetti di Sicurezza devono essere al centro delle attenzioni dei team di delivery? Ovviamente, no! Ma forse può esserci d’aiuto per “rinfrescarci” la memoria.

Abbiamo più volte parlato di sicurezza, anche in relazione al mondo dell’IoT, raccontando come, ad esempio, AgileIoT ponga questo aspetto nei “ballons” fondamentali per la produzione di soluzioni massive di mercato. In ugual modo lo fano Disciplined Agile 2, SAFe e gli altri framework di scaling, per non parlare di Lean. Anche l’ISO ha formalizzato da tempo il proprio standard a riguardo, ovvero l’ISO 27001, che molte aziende si stanno quanto meno impegnando a “capire”.

secdevops

Sia che vogliate chiamarlo SecOps, DevSecOps, SecDevOps, o diversamente, resta il fatto che la Sicurezza è un vostro problema, e come tale dovete ponderare il vostro lavoro quotidiano in sua funzione. L’approccio che si cela dietro questi acronimi trova le fondamenta nel Threat modeling, dove si cerca, pragmaticamente, di identificare, enumerare e priorizzare gli ipotetici rischi ponendosi nei panni di colui che prova a violare i nostri sistemi.

Gli aspetti operativi di questo approccio si legano al value stream generale, specializzandosi in specifiche azioni da parte dei Devs e degli Ops. Un elemento da sottolineare è che applicando DevOps in tutta la sua potenzialità, ottenendo quindi un ambiente di delivery estremamente dinamico, si ha la necessità di rendere tale anche l’approccio alla sicurezza, concretizzando un “fast security approach” (the third way: learning), in modo da avere processi sempre aggiornati ed evitare l’accumulo di debito tecnico in tale area.

Diventa così evidente come ogni nuova iniziativa nasca di base con una serie di quesiti annessi:

  • Quali sono i dati che (andremo) si andrà a raccogliere?
  • Come verranno protetti i dati da attacchi interni ed esterni?
  • Qual è la sicurezza degli ambienti in cui le soluzioni vengono rese disponibili?
  • Che cosa si è imparato dall’esperienza e dalle release precedenti?
  • Quali sono le principali sfide incontrate?

Si tratta di tasselli estremamente importanti nell’impostazione generale del progetto, tanto da impattare, ad esempio, sulla Definition of Done e, di conseguenza, sull’effort complessivo (the first way: flow).

Se si va poi a guardare più da vicino le attività dei Developer, si evidenziano aspetti direttamente correlati alle attività di sviluppo in un’ottica di “secure engineering” (the first way: flow):

  • Implementare modelli adeguati di crittografia e di protezione dei dati;
  • Integrare scansioni di sicurezza automatizzati nei processi di sviluppo e condividerne rapidamente i risultati;
  • Coinvolgere gruppi di “hacking etico” per rafforzare la capacità di realizzare ed eseguire test di penetrazione sempre più efficaci;
  • Fare delle considerazioni sul possibile utilizzo malevole delle API pubbliche e registrarne gli abusi nei sistemi di monitoring;
  • Inserire nel codice strumenti di logging non-invasivo per tracciare adeguatamente i fault di sicurezza;
  • Essere costantemente aggiornati sulle nuove tipologie di attacchi e sulle tecniche di risposta e prevenzione;
  • Sperimentare e condividere successi e fallimenti.

Parallelamente, gli Operation hanno in dote tutti quegli approcci e quelle tecniche che mirano a rendere sicuri gli ambienti di erogazione e raccogliere dati a riguardo (the second way: feedback):

  • Osservare cosa accade in seguito ai nuovi rilasci e come essi impattano sui livelli di sicurezza;
  • Assicurarsi che i software di base siano dotati degli ultimi aggiornamenti;
  • Validare costantemente le autorizzazioni d’accesso e proiettarle verso il livello minimo;
  • Assicurarsi che le diverse postazioni operative siano utilizzate solo da utenti autorizzati;
  • Settare strumenti di monitoraggio, attivi e passivi, che consentano di verificare lo stato di sicurezza in modo automatizzato e creare feedback rapidi sulla base delle informazioni ottenute;
  • Attuare scansioni di networking e tentativi di intrusione per validarne la robustezza;
  • Registrare qualsiasi anomalia e classificarla in funzione dei rischi;
  • Trasparenza e condivisione dello stato generale.

Come ripetiamo da tempo, realizzare oggi una soluzione IT ha un grado di complessità e di ingegnerizzazione completamente diverso da quello di soli cinque anni fa, per cui è necessario una nuova cultura e nuove competenze, permettendo così di sfruttare, inoltre, adeguatamente anche le nuove tecnologie a disposizione.

 

Stay tuned :-)

Build: I minuti sono tornati

Se avete attivato la nuova Home Page dell’account sul vostro Visual Studio Team Services, avrete sicuramente notato che il riepilogo dei minuti di build gratuiti è sparito. Il problema è che non solo è stato tolto dalla pagina iniziale, ma non era stato inserito in nessun’altra schermata.
Finalmente, però, abbiamo di nuovo la possibilità di visualizzare il contatore. Per farlo, bisogna andare sulle impostazioni dell’account, sotto Build and Release, Resource limits:

 Festeggiamo! I minuti sono tornati :)

Agile@School 2017 – I progetti

Sabato scorso, con i team definiti nell’incontro precedente, abbiamo parlato di analisi dei requisiti, partendo dalla customer journey che gli studenti hanno creato appositamente. Come mi aspettavo, quest’ultimo compito è risultato più arduo di quanto i ragazzi credessero. Non è infatti facile avere le idee chiare su quello che si vuole ottenere, anche se l’idea di fondo del progetto è apparentemente solida. Parlandone insieme e facendosi qualche domanda in più a mo’ di brainstorming, sono emerse tutte le normali lacune di chi non è abituato a pensare a veri progetti. 

Risultato? Non avevamo nemmeno una customer journey.
Come fare? Semplice, Gabriele ed io abbiamo seguito team per team, sia dando consigli sul “cosa fare” per chi era a corto di idee, sia discutendo la forma da seguire per ottenere risultati efficaci.
Come in ogni percorso, abbiamo perso un paio di ragazzi, i quali hanno preferito seguire un iter solitario. Parlo anche di queste persone perchè, nonostante la strada intrapresa, sono stati con noi, e ci hanno pure aiutato a costruire le board di cui parleremo a breve. Il tutto nello spirito di aiuto e condivisione. Ed è decisamente importante; un valore aggiunto non da poco. 
Possiamo dire di avere infine sei squadre, con altrettanti progetti:
Come si vede nella foto, il primo step è stato raccogliere una board. L’idea è quella di fare la story map, ovvero una bacheca in cui apporre post-it di colore differente, con la quale descrivere le funzionalità del software (o di altro, come l’utilizzo di hardware, il dialogo di bot, ecc.). Si tratta di un’implementazione molto semplice, se si conoscono già le funzionalità da offrire. Immaginate di avere una linea principale in cui rappresentare le feature principali ed almeno una secondaria in cui indicare le attività da implementare. Orizzontalmente le feature, e verticalmente il loro sviluppo. In verticale anche la profondità fino a cui arrivare, versione per versione. Ecco come appare:
La riga a matita, la quale esclude l’ultimo post-it blu, è la v1.0. Al di sotto di essa, la 2.0.
Dalla board ricaveremo le epiche e i PBI da aggiungere a Visual Studio Team Services, in modo da creare una rappresentazione virtuale della stessa. Utilizzeremo anche la funzionalità denominata swimlane, al fine di creare all’interno dello stesso spazio più board, una per ogni progetto/team. 
Da qui si inizierà con il vero sviluppo e con la riorganizzazione delle bacheche quando e laddove richiesto. I presupposti ci sono, le idee sono buone ed anche l’innovazione è presente nei pensieri dei ragazzi. Avremo, se tutto andrà come dovrebbe, un’automobile intelligente comandata da smartphone (Raspberry), un sistema di allarme domestico (Arduino), un paio di chatbot (senza intelligenza artificiale), una chat per la produttività dei team ed un progetto di riconoscimento facciale. Da rimanere a bocca aperta! Il problema è: “ce la faremo?”, proviamoci!
Stay tuned! 

BugGuardian per ASP.NET Core

C’è un nuovo membro nella famiglia BugGuardian.
Un po’ di tempo fa ho rilasciato BugGuardian, una libreria che permette di create un work item di tipo Bug o Task sia su Visual Studio Team Services sia su Team Foundation Server, nel caso in cui la nostra applicazione sollevi un’eccezione non gestita. (Maggiori informazioni qui).
Dopo un po’, si sono aggiunte altre due librerie: BugGuardian.WebForms e BugGuardian.MVC. Come dice il nome, la prima è pensata per ASP.NET WebForms e l’altra per ASP.NET MVC, e servono per semplificare ulteriormente l’adozione della libreria a chi utilizza quelle piattaforme. Ma hanno un limite: funzionano solamente con ASP.NET tradizionale, su .Net Framework.
Oggi sono felice di annunciare che l’estensione BugGuardian.AspNetCore è finalmente disponibile.
BugGuardian.AspNetCore è stata sviluppata per supportare specificamente le webapp ASP.NET Core. Aggiunge un middleware all’applicazione che permette di intercettare automaticamente tutte le eccezioni non gestite.
E la cosa positiva è che supporta sia i progetti ASP.NET Core che utilizzano il full Framework sia quelli scritti con NetCore.
Potete trovare il codice sorgente (e tutte le informazioni sulla configurazione della libreria) su GitHub: https://github.com/n3wt0n/BugGuardian.AspNetCore
Il pacchetto è anche disponibile su NuGet: https://www.nuget.org/packages/DBTek.BugGuardian.AspNetCore
Happy Coding :)