Author Archives: Felice Pescatore

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

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

DevOps è Cultura… ma cos’è la Cultura?

Tornando nei giorni scorsi da due importanti eventi, l’Agile Lean Conference Italia e Agile for Innovation, ho avuto tempo di riflettere in treno (complice il solito ritardo che stavolta ha superato gli 80 minuti) su una cosa: durante i miei interventi su DevOps mi soffermo sempre a sottolineare più volte come DevOps sia Cultura!

culture behaviour

Fin qui, nulla da recriminare a me stesso, ne sono profondamente convinto ed è un punto fermo di tutto il movimento che ruota, con cognizione di causa, intorno a questa filosofia nata (o meglio esplicitata) nel 2009 quando Patrick Debois da vita al DevOpsDays in Belgio e conia il termine stesso DevOps.

Al tempo, Debois è reduce da una consulenza per un’azienda governativa in cui il maggiore ostacolo incontrato è quello della completa assenza di comunicazione tra Dev e Ops, tanto da sentirsi frustrato nel non capire il perché di questa condizione paradossale.

Il problema era tutto nell’atteggiamento, o meglio ancora nei comportamenti che le due anime dell’IT avevano l’uno nei riguardi dell’altro: ogni gruppo si sentiva “superiore” e considerava l’altro una “zavorra” di cui non era possibile liberarsi e di conseguenza da relegare in un angolo.

Quindi, il come ci si pone rispetto ai nostri colleghi diretti, caratterizza la Cultura aziendale nel suo insieme, andando a connotare l’azienda stessa e la sua capacità di rispondere ai cambiamenti. La tematica è straordinariamente interessante, e per sintetizzarla possiamo prendere in prestito il concetto di Sfera di Influenza che l’amico Andrea Provaglio utilizza frequentemente per descrivere egregiamente la differenza tra Management e Leadership: ognuno di noi è leader almeno di sé stesso (ok, se non lo è i problemi sono diversi), per cui ognuno di noi ha una propria sfera di influenza che può assumere un volume più o meno ampio a secondo della capacità che abbiamo di influenzare gli altri.

I punti di intersezione delle diverse sfere di influenze rappresentano il contatto in cui i diversi gruppi aggregati (con il limite inferiore tendente a un componente) si confrontano partendo dalle proprie esperienze, anche diverse, che in qualche modo devono amalgamarsi per consentire al flusso generale delle attività di scorrere adeguatamente verso l’obiettivo di generare Valore. Se si riflette su questi aspetti, l’evidenza è straordinariamente ovvia: fino a che si resta nella nostra confort zone, siamo protetti, ci sentiamo sicuri e tutto fila per il meglio. Quando dobbiamo metterci in gioco, quest’area di sicurezza diventa instabile e i nostri comportamenti sono una risposta al cambiamento e al nuovo equilibrio da raggiungere.

Diventa così esplicito che la Cultura aziendale sia la capacità dell’organizzazione di accrescere la propria resilienza e rispondere adeguatamente ai cambiamenti radicali (kaikaku) che si affiancano a quelli graduali (kaizen), impliciti o e espliciti che siano.

Quando sentiamo delle affermazioni tipo: “questo approccio non si adatta alla nostra Cultura aziendale”, si evidenzia una implicita resistenza al cambiamento che sottolinea un nostro comportamento conservativo, dietro il quale si cela la non volontà di mettersi in gioco e impegnarsi a trovare un nuovo punto di equilibrio nell’orizzonte (landascape) organizzativo.

Volendo sintetizzare, possiamo affermare che:

la Cultura aziendale è l’insieme dei comportamenti che ogni membro dell’organizzazione ha nel confronto dei propri colleghi e nella risposta alla necessità di cambiamento proveniente da fattori esterni

e quindi:

per cambiare la Cultura organizzativa, potete e dovete cambiare i vostri Comportamenti

(e ciò si trasformerà nella nuova Cultura organizzativa)

Stay tuned J

Il movimento Agile sbarca al sud

2017 agile o day logo

L’Agile Community Campana, associazione nata lo scorso anno, è orgogliosa di annunciare che il 12 maggio 2017 ci sarà il primo Agile Open Day a Napoli, organizzato con la Facoltà di Ingegneria dell’università Federico II di Napoli e l’Italian Agile Movement.

È la prima volta che uno degli eventi afferenti al mondo Agile si tiene nelle regioni del Sud, nonostante la tematica sia estremamente importante, soprattutto per le aziende che fanno dell’IT uno dei propri fondamentali.

Esperti di tutta Italia saranno a Piazzale Tecchio a Napoli (sede della facoltà di Ingegneria) per raccontare esperienze concrete nel contesto italiano, utili a capire perché Agile, Lean, DevOps e gli altri approcci affini, abbiano un’importanza strategica nel contesto nazionale per qualsiasi azienda che voglia rispondere efficacemente alle perturbazioni del mercato.

Nessun dubbio quindi sull’opportunità di ascoltare e confrontarsi ai massimi livelli su queste tematiche, assaporando anche l’ospitalità che da sempre caratterizza i nostri territori.

L’invito è quello di iscrivervi subito all’evento tramite la pagina ufficiale: http://www.agilecommunitycampania.it/agile-open-day/ e, se avete storie da raccontare, inviare una vostra proposta di intervento che sarà valuta dall’apposita commissione che ha il compito di redigere l’agenda finale.

Sempre allo stesso indirizzo potete seguire l’evoluzione degli aspetti organizzativi e, in caso abbiate qualsiasi domanda, potete scriverci all’indirizzo email: info@agilecommunitycampania.it

Ci vediamo il 12 maggio a Napoli!

Felice Pescatore, Agile Community Campania

DevOps, Agile e Lean: non è più concesso ignorarli

DevOps è diventato ormai il killer-approach per la delivery di soluzioni che siano in grado di avere un basso time-to-market e ottimizzare l’intero value stream aziendale annesso.

Devo ammettere che da sempre considero DevOps la naturale estensione dell’Agile, con una positiva contaminazione dei principi Lean (che ricordo sono derivati dal mondo manifatturiero), cosa che mi porta ad amare poco il termine “DevOps” in sé perché, almeno lessicalmente, sembra limitare il tutto ai Developer ed agli Operation oltre che all’ambito IT.

solution s curve

Detto questo, è importante evidenziare che DevOps non “appartiene” solo al mondo dell’IT, bensì è un approccio che spinge a far propri i 3 principi portanti: Flow, Feedback e Learning (così come sono oggi riformulati rispetto alla prima enunciazione), per un’azione efficace nella creazione di Servizi e Prodotti negli ambiti più diversi. A tal proposito segnalo l’interessante approfondimento degli amici di AgileReloaded: L’orizzonte allargato di Agile.

Resta comunque indubbio che l’IT è la culla di DevOps, trasformando gradualmente le azioni annesse allo sviluppo di soluzioni complesse da attività “artigianali” ad attività più “ingegneristiche”, con precisi elementi di riferimento. Ciò fa si che le aziende percepiscano sempre più il proprio IT per quello che deve essere: un Asset strategico al servizio del Business e non un Centro di Costo.

E le parole sono estremamente importanti: parlare di “divisione IT” porta ad immaginare un Silos a sé stante con regole proprie e ben identificabili. Ciò è quanto di più semplicistico si possa immaginare perché l’IT è estremamente pervasivo e condiziona, restandone a sua volta condizionato, tutte le aree aziendali.

La centralità di DevOps, anche se non del tutto maturata nel nostro contesto nazionale, è confermata da un’indagine di IDC che oggi ne vede l’adozione in oltre il 70% delle principali aziende mondiali (con livelli diversi e penetrazione diversa) e stima il superamento della soglia dell’80% entro il 2019.

Ma questa penetrazione così profonda, quali sfide comporta?

Anche qui dobbiamo avere una visione olistica del contesto poiché molte aziende che provano a sperimentare DevOps su un progetto pilota o un’area di riferimento, si accorgono rapidamente che è necessario coinvolgere tutte le diverse funzioni aziendali, per cui lo Scaling diventa inevitabile e anche estremamente veloce.

Ma torniamo alla nostra precedente domanda, andando ad evidenziare le sfide primarie che ogni azienda incontra nell’adozione concreta di DevOps e, quindi, nel profondo percorso di trasformazione e cambiamento Culturale:

  • Sponsorship aziendale: adottare DevOps significa investire e avere pazienza nell’ottenere risultati tangibili localizzati a breve termine, ma complessivamente visibili nel medio termine. L’investimento è sia in termini finanziari che in termini di impegno delle Persone (vi prego… non usate il termine “risorse” per indicarle!), per cui solo se è uno dei massimi dirigenti aziendali (CxO) a supportarla, l’adozione potrà avere il sostegno necessario e raggiungere risultati lusinghieri;
  • Abbandonare le rigide strutture di controllo del passato: una Cultura volta al continuo miglioramento, basata su applicazioni empiriche, mal si lega con una organizzazione aziendale basata sul pattern command-and-control, in cui è difficile cambiare. I manager devono imparare a delegare, mentre le linee più operative ad avere coraggio, cercando di rendere la struttura più flessibile ma soprattutto focalizzata sul value stream;
  • Il Core know-how deve essere in azienda: considerare l’IT un “centro di costo” ha portato negli anni ad abusare dell’outsourcing, perdendo conoscenza, controllo e capacità di gestire le nuove sfide di mercato. Questa tendenza deve trasformarsi in un’outsourcing bilanciato in cui gli elementi chiave, per rispondere efficacemente e prontamente al Business, sono all’interno e ci si appoggia ad un’outsourcing controllato per gli elementi corollari (abbiamo parlato abbondantemente di questo aspetto nella serie DevOps and Outsourcing: OutOps);
  • Ridurre la resistenza al cambiamento: DevOps è Cultura, e una trasformazione aziendale nella sua direzione comporta nuovi modelli organizzativi, nuovi ruoli e un diverso approccio alle prospettive di carriera. Questi aspetti spingono ad aumentare la resistenza al cambiamento per restare nella propria “confort zone” e ridurre al minimo la necessità di rimettersi in discussione. È compito dell’organizzazione fare chiarezza su questi aspetti e creare le opportunità a sostegno dei desideri intersechi (leggasi Management 3.0) ed estrinsechi di ogni singolo collaboratore;
  • Fail Fast o meglio… Learn Fast: il fallimento è una componente poco desiderata ma fortemente presente, e a volte indispensabile, nel mondo dei sistemi complessi. Il mantra non deve essere: “non fallire mai…” ma “fallire il meno possibile e quando accade far tesoro del fallimento stesso”. In pratica ogni fallimento diventa un tassello nel cambiamento e nell’ottimizzazione complessiva… chiaramente questo non vuol dire fallire sempre!
  • Mai applicare qualcosa “out-of-the-book”: DevOps è un cambiamento culturale da ricamare nel proprio contesto e come tale necessita di essere capito profondamente nelle sue varie sfaccettature. Non basta comprare un libro e leggere qualche blog per iniziare la propria trasformazione: il rischio di fallimento è estremamente elevato! Meglio affidarsi al supporto di professionisti che accompagnano l’organizzazione a muovere i primi passi e ad individuare gli elementi focali che consentono affacciarsi al mondo DevOps con maggiore fiducia e minori incertezze.

Se tutto questo vi spaventa o vi fa tornare nel “vostro mondo” fatevi una domanda: possiamo permetterci di non cambiare quando tutto sta evolvendo ad un ritmo frenetico ed inarrestabile?

In fondo bisogna lasciare andare il passato per essere padroni del futuro.

Stay tuned J

DevOps and Outsourcing: OutOps [pt.3]

Terzo e ultimo appuntamento di DevOps e Outsourcing, in cui vedremo le rimanenti strategie e tireremo un po’ le somme del discorso.

OutOps Strategy, Infrastructure Resilience

L’ Infrastructure Resilience (Resilienza ai cambiamenti Infrastrutturali) è la capacità del software di adattarsi ai cambiamenti evolutivi e alle condizioni inattese dell’infrastruttura a supporto, composta dall’hardware e dal software di base.

resili

In generale, una soluzione robusta deve essere tollerante ai cambiamenti dell’hardware e del software di base: si pensi, ad esempio, all’utilizzo di container per il suo dispiegamento.

In questo ambito è fondamentale avere strumenti automatizzati di verifica che consentono al committente di validare il corretto utilizzo dell’infrastrutture da parte della soluzione realizzata.

Questo approccio conferisce al delivery/deploy automatizzato una maggiore robustezza: si pensi ad esempio ad una nuova release del software che si scontra con il fatto che l’RDBMS è stato aggiornato. Se le verifiche vanno a buon fine è possibile essere confidenti che l’evoluzione infrastrutturale non ha prodotto side effect sull’applicazione e procedere con il relativo delivery. L’alternativa sarebbe un approccio “deploy & pray”, ovvero “io speriamo che me la cavo”.

Compito del Committente: Definire e gestire gli end-point di supporto alle soluzioni unitamente al provisioning automatizzato delle risorse annesse. Inoltre, è di primaria importanza l’individuazione o la realizzazione di tool che consentano di verificare lo stato di erogazione del servizio e rispondere autonomamente alle situazioni inattese più comuni.

Benefici Evidenti: garantire una buona resilienza consente di supportare adeguatamente l’evoluzione dell’infrastruttura a supporto, riducendo il rischio di blocco dei servizi e quindi un’operatività dell’azione di business.

OutOps Strategy, Intentional Architecture

Ogni software ha un’Architettura, sia essa specificamente definita o de-facto.

intentional architect

Quello che però deve essere evidente è il fatto che, a livello di “piattaforma” (formata dalle diverse soluzioni, realizzate eventualmente in outsourcing da uno o più fornitori) delle soluzioni erogate, non è possibile immaginare che ognuna di essa abbia una struttura che non tenga conto delle scelte d’insieme e, in particolare, non sposi architetture software moderne, andando a minare l’efficienza complessiva di una pipeline di Continuous Delivery.

Come esempio, si immagini lo scenario in cui la soluzione è monolitica e si debbano eseguire i test di regressione: per testare le modifiche relative ad una singola feature è necessario ricompilare tutto il sorgente e rieseguire tutti i test, perdendo ore e rendendo impossibile, nel concreto, attuare la pratica di Continuous delivery/deploy. Un’architettura in chiave “servizi” (nelle diverse declinazioni tecnologiche), consente di rendere il tutto estremamente più efficiente, concentrando le azioni di verifica e misurazione esclusivamente sul nuovo componente o su quello che è stato modificato.

Una soluzione efficace al problema è quella che vede il committente impegnato a definire una “Intentional Architecture” (Architettura Intenzionale), ovvero una architettura di riferimento che guidi le azioni progettuali del fornitore senza imbrigliarlo in scelte eccessivamente di dettaglio: ad esempio, si impone che l’architettura sia a Microservizi, ma al contempo al fornitore non viene imposto di utilizzare uno specifico design pattern perché si tratta di una scelta a livello di codifica (design applicativo), ininfluente a livello architetturale.

Compito del Committente: Definire l’Intentional Architecture e condividerla in modo chiaro con tutti i fornitori. Settare una serie di metriche che consentano, qualitativamente, di validare l’aderenza ad essa.

Benefici Evidenti: Con una Intentional Architecture si riduce fortemente il rischio di frammentazione della “piattaforma”, consentendo una gestione quanto più possibile omogena di essa. Inoltre, le architetture moderne abilitano all’utilizzo di molte delle pratiche alla base di DevOps.

OutOps Strategy, Security Validation

La Sicurezza (con la “S” maiuscola ad indicare la generalità e la necessità di declinarla rispetto allo specifico contesto) è un aspetto imprescindibile che deve essere alla base della realizzazione di ogni soluzione.

security 

Fondamentale è che le diverse applicazioni siano allineate alle necessità e ai vincoli individuati a livello enterprise al fine di non compromettere la sicurezza della “piattaforma” complessiva dei servizi in erogazione.

Questo tipo di azione richiede la creazione di una serie di servizi che i fornitori debbono utilizzare per validare quanto realizzato già durante lo sviluppo: si pensi ai penetration test, così come agli strumenti di analisi statica della qualità del codice che si concentrano sulla ricerca di pattern potenzialmente attaccabili.

Finché tutte le verifiche non sono superate positivamente, la soluzione non può essere accettata e sarà onere del fornitore risolvere i diversi problemi riscontrati.

Compito del Committente: Definire in modo chiaro il concetto di “Sicurezza” e le relative policy a cui attenersi, rendendo disponibili una serie di strumenti che il fornitore può utilizzare per validare oggettivamente la relativa conformità.

Benefici Evidenti: La “piattaforma” dei servizi ha un livello di Sicurezza minimo garantito. Il committente è sicuro che, solo quando una soluzione supera le verifiche automatiche di sicurezza stabilite nella pipeline di delivery, potrà raggiungere effettivamente la produzione.

 

Conclusioni

Quanto descritto fin ora vuole essere un contributo, sulla base dell’esperienza personale e dell’osservazione diretta di diverse realtà aziendali, nel capire come poter applicare i principi DevOps in contesti fortemente caratterizzati da azioni di outsourcing.

Si tratta di casi numericamente consistenti, in cui diventa difficile trovare il modo di sposare le pratiche che stanno gradualmente trasformando lo sviluppo, di soluzioni IT, da un’azione artigianale ad una sempre più ingegneristica.

Bisogna però fare attenzione a non cadere nell’illusione che OutOps possa richiedere un impegno minore, dal punto di vista della trasformazione aziendale, di quello che possa richiede DevOps: questo perché l’onere di guidare il processo di trasformazione in relazione agli obiettivi di business non può essere esternalizzato, ma resta di competenza esclusiva dell’IT aziendale, essendo l’unico responsabile dell’allineamento con la vision strategica.

Fondamentale diventa, inoltre, il coinvolgimento di funzioni non tipicamente IT, come Legal o Provisioning, che devono formalizzare e gestire le relazioni con i fornitori esterni. Tematica particolarmente calda in questo ambito è quello dei Contratti Agili, pensati per instaurare una collaborazione win-win tra committente e fornitore che non si basi esclusivamente sugli elementi costo-tempo-funzionalità.

Infine, è utile ribadire che, quanto descritto, è un’indicazione di cosa ad oggi funziona nelle realtà che si sono impegnate in OutOps, e non va preso come una “ricetta” ma come un punto di partenza per capire come potersi muovere nel proprio contesto.