Continuiamo il nostro viaggio nell’applicazione di DevOps al mondo dell’Outsourcing. 

OutOps Strategies

Fatte fin qui le dovute premesse ed i dovuti richiami, andiamo ora a vedere le strategie attualmente più efficaci in ambito OutOps:

• Shared Repository
• Regression Test
• Quality Measurement
• Infrastructure Resilience
• Intentional Architecture
• Security Validation

Queste strategie consentono all’IT del committente di mantenere il controllo su quanto realizzato da uno o più fornitori terzi, attuando una governance efficace di supporto al business. Si tratta di mettere in chiaro gli elementi essenziali su cui si svilupperà il rapporto committente/fornitore in modo da non essere preda di “capricci” o azioni poco ortodosse da una delle parti.

Qui è necessario aprire una parentesi: l’idea di dare in outsourcing l’intera attività di sviluppo è un forte azzardo che può portare a risparmi, anche consistenti, nell’immediato, ma espone l’azienda a rischi altissimi per il futuro. Si prenda ad esempio lo scenario in cui lo sviluppo di tutto il software relativo al core-business viene esternalizzato: in questo caso, per la prima release, è probabile che si otterrà un cospicuo sconto da parte del fornitore che vuole entrare nelle “grazie” dell’azienda. Ma già dalla release successiva (se non prima!) le posizioni saranno invertite: le regole del gioco saranno dettate dal fornitore perché detiene le “chiavi” del successo del business.

Una corretta strategia di Program dovrebbe essere quella di mantenere lo sviluppo dei sistemi core in-house ed esternalizzare solo quello relativo alle soluzioni di supporto o comunque relativamente facili da sostituire.

In entrambi i casi, le strategie di OutOps sono preziose per garantire una costante efficienza dell’azione IT.

OutOps Strategy, Shared Repository

La strategia di Shared Repository consente di attivare il flusso di “Last Mile” (“Ultimo Miglio”), ovvero quello che porta il software dal Version Control System nelle «mani» dell’utente finale.

Tipicamente, ogni team di sviluppo e ogni team di operation definisce il modo in cui il software viene versionato, compilato, impacchettato, dispiegato, ecc… Chiaramente, nello scenario di sviluppo in-house, l’approccio DevOps consente di trovare il miglior compromesso contestuale per raggiungere efficacemente gli obiettivi fissati.

In un’ottica OutOps invece, la strategia di Shared Repository mette a disposizione un VCS unico, gestito dal committente, che diventa il “punto di scambio primario” tra il team esterno e quello interno di “Ops”. In particolare, il fornitore deve conformarsi alle regole di versioning identificate dal committente e garantire che quanto presente su di esso sia compilabile.

Tutto questo è indispensabile per creare una strategia di building automatizzata con cui realizzare gli artefatti che poi attraverseranno i diversi ambienti di QA Testing, Pre-Prod, Collaudo… fino ad arrivare in produzione.

Non è assolutamente pensabile che ogni fornitore gestisca questi aspetti in modo autonomo, perché ciò porterebbe ad una giungla di soluzioni e di convenzioni che renderebbero difficile, se non in alcuni casi impossibile, gestire il tutto.

Compito del Committente: Gestire il Version Control System da utilizzare e definire un’opportuna strategia di versioning a cui tutti i fornitori dovranno attenersi.

Benefici Evidenti: Il software realizzato in outsourcing è sempre presente nel repository del committente, seguendone le regole di versionamento e di gestione. Tutto quanto necessario è presente nello specifico ramo del source control (codice, dipendenze, test, documentazione, ecc…) ed è possibile impostare azioni consistenti e predicibili (a partire dalla build) per completare l’ultimo miglio, con la certezza di non doverle rivedere per ogni fornitore.

OutOps Strategy, Regression Test

I Regression Test (o Test di Regressione) devono sempre accompagnare il software sviluppato, al di là che si utilizzi un approccio OutOps. I Test di Regressione vanno a verificare che quanto sviluppato (storia o feature) funzioni correttamente e produca gli output previsti in relazione al perimetro delineato dai relativi Criteri di Accettazione.

Tali test sono, inoltre, un’ottima fonte di documentazione (estraibile tramite tool automatici) che riflette costantemente lo stato reale di quanto sviluppato.

Compito del Committente: Lavorare con il team del fornitore per la definizione di Regression Test, annessi ai Criteri di Accettazione, che consentano di validare il corretto funzionamento di quanto realizzato e delle eventuali modifiche apportate.

Benefici Evidenti: I Regression Test sono fondamentali per garantire al committente la possibilità di far evolvere la soluzione in modo indipendente dal fornitore specifico. Ciò allenta drasticamente il cordone ombelicale che lega tra loro committente e fornitore, fino a spezzarlo completamente se necessario.

OutOps Strategy, Quality Measurement

Misurare la Qualità del Software realizzato è essenziale per valutare il lavoro svolto dal fornitore, ma soprattutto consente di tenere sotto controllo il Debito Tecnico cumulativo, evitando che si avvicini al punto di massa critica.

È fondamentale quindi settare dei livelli minimi di qualità del codice, statici e dinamici, e individuare tool che possano misurarli automaticamente. Tali livelli dovranno essere rispettati e raggiunti da tutti i fornitori, altrimenti quanto depositato nel sistema di versionamento non può essere immesso nella pipeline di delivery e viene scartato automaticamente.

Tutti i problemi riscontrati devono inoltre confluire in un sistema di Change Request Management (o similare) che li rendi evidenti e che consenta di misurare il relativo trend in modo da intraprendere opportune azioni correttive a riguardo.

Compito del Committente: Definire livelli minimi di qualità che le soluzioni devono avere e le relative Metriche di valutazione. Queste informazioni devono essere chiare e disponibili in modo trasparente, oltre ad essere validate attraverso tool automatici messi a disposizione anche al fornitore per testare il proprio lavoro durante la fase di sviluppo.

Benefici Evidenti: Quanto realizzato ha un livello minimo di qualità, individuato dal committente, che minimizza i rischi al minimo livello accettabile. L’automazione consente di rimuovere gli approcci basati su verifiche manuali delle tradizionali milestone che spesso finiscono più per essere un’azione pro-forma che di reale utilità. Inoltre, il Debito Tecnico è costante monitorato ed è indicativo dello stato di salute di tutte le soluzioni software in essere.

Con “la misura” si conclude il nostro secondo appuntamento. La prossima settimana completeremo l’esplorazione delle altre tre strategie evidenziate.

Stay tuned