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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Test Plans
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.
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à.
LaunchDarkly rollout work item
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:
Login