Sviluppo basato su test per le zone di destinazione di Azure
Lo sviluppo basato su test (TDD) è un processo di sviluppo software e DevOps che migliora la qualità delle nuove funzionalità e miglioramenti nelle soluzioni basate su codice. TDD crea unit test case prima di sviluppare il codice effettivo e testa il codice nei test case. Questo approccio è contrario allo sviluppo del codice prima e alla creazione di test case in un secondo momento.
Una area di atterraggio è un ambiente per l'hosting di carichi di lavoro di cui è stato eseguito il preprovisioning tramite codice. Le zone di destinazione includono funzionalità fondamentali che usano un set definito di servizi cloud e procedure consigliate. Questo articolo descrive un approccio che usa TDD per implementare landing zones di successo soddisfacendo i requisiti di qualità, sicurezza, operazioni e governance.
L'infrastruttura cloud è il risultato dell'esecuzione del codice. Codice ben strutturato, testato e verificato produce una zona di atterraggio funzionale. L'infrastruttura basata sul cloud e il relativo codice sorgente sottostante possono usare questo approccio per garantire che le zone di destinazione siano di alta qualità e soddisfino i requisiti principali.
Usare questo approccio per soddisfare richieste di funzionalità semplici durante lo sviluppo anticipato. Più avanti nel ciclo di vita di adozione del cloud, è possibile usare questo processo per soddisfare i requisiti di sicurezza, operazioni, governance o conformità. Il processo è particolarmente utile per lo sviluppo e il refactoring delle aree di approdo in un'attività di sviluppo parallelo.
Ciclo di sviluppo basato su test
Il diagramma seguente illustra il ciclo di sviluppo basato su test per le zone di destinazione di Azure:
Crea un test. Definire un test per verificare che siano stati soddisfatti i criteri di accettazione per una funzionalità. Automatizzare il test durante lo sviluppo, per ridurre la quantità di lavoro di test manuale, soprattutto per le distribuzioni su scala aziendale.
Testare la zona di destinazione. Eseguire il nuovo test ed eventuali test esistenti. Se la funzionalità richiesta non è inclusa nelle offerte del provider di servizi cloud e non è stata fornita dalle attività di sviluppo precedenti, il test dovrebbe non riuscire. L'esecuzione di test esistenti consente di verificare che la nuova funzionalità o il test non riduca l'affidabilità delle funzionalità esistenti della zona di destinazione.
Espandere e ristrutturare la zona di atterraggio. Aggiungere o modificare il codice sorgente per soddisfare la funzionalità di aggiunta di valore richiesta e migliorare la qualità generale della codebase.
Per soddisfare i criteri TDD, il team della piattaforma cloud aggiungerà codice solo per soddisfare la funzionalità richiesta. Tuttavia, la qualità e la manutenzione del codice sono attività condivise. Man mano che soddisfano nuove richieste di funzionalità, il team della piattaforma cloud deve provare a migliorare il codice rimuovendo la duplicazione e chiarire il codice. È consigliabile eseguire test tra la creazione di nuovo codice e il refactoring del codice sorgente.
Distribuire la zona di atterraggio. Una volta che il codice sorgente risponde alla richiesta di funzionalità, implementare la zona di atterraggio modificata presso il provider cloud in un ambiente di test controllato o sandbox.
Testare la zona di destinazione. Ritestare la zona di atterraggio per verificare che il nuovo codice soddisfi i criteri di accettazione per la funzionalità richiesta. Una volta superati tutti i test, la funzionalità viene considerata completa e i criteri di accettazione vengono considerati soddisfatti.
Il ciclo TDD ripete i passaggi di base precedenti fino a quando non soddisfano la definizione completa di. Quando tutte le funzionalità a valore aggiunto e i criteri di accettazione superano i loro test associati, la zona di atterraggio è pronta a supportare la prossima ondata del piano di adozione del cloud.
Il ciclo che rende efficace il TDD viene spesso definito test rosso/verde. In questo approccio, il team della piattaforma cloud inizia con un test fallito, o test rosso, in base alla definizione di completato e ai criteri di accettazione definiti. Per ogni funzionalità o criterio di accettazione, il team della piattaforma cloud completa le attività di sviluppo fino al termine del test o ha un test verde.
L'obiettivo di TDD è quello di affrontare una progettazione migliore, non creare un gruppo di test. I test sono un elemento prezioso per completare il processo.
Definizione dell'operazione completata
Il successo può essere una misura soggettiva che fornisce a un team della piattaforma cloud poche informazioni utili durante lo sviluppo o il refactoring della zona di approdo. La mancanza di chiarezza può causare aspettative e vulnerabilità mancanti in un ambiente cloud. Prima che il team della piattaforma cloud eselabori o espandi le zone di destinazione, deve cercare chiarezza riguardo alla definizione di eseguita (DoD) per ogni zona di destinazione.
DoD è un semplice accordo tra il team della piattaforma cloud e altri team interessati che definisce le funzionalità a valore aggiunto previste da includere nello sforzo di sviluppo della zona di atterraggio. Il DoD è spesso un elenco di controllo allineato al piano di adozione del cloud a breve termine.
Man mano che i team adottano più carichi di lavoro e funzionalità cloud, il DoD e i criteri di accettazione diventano più complessi. Nei processi maturi, le funzionalità previste hanno i propri criteri di accettazione per fornire maggiore chiarezza. Quando le funzionalità a valore aggiunto soddisfano tutti i criteri di accettazione, la zona di atterraggio è sufficientemente configurata per garantire il successo dell'attuale ondata di adozione o rilascio.
Esempio di DoD semplice
Per un'operazione di migrazione iniziale, il DoD potrebbe essere eccessivamente semplice. L'esempio seguente è un DoD semplice:
La zona di destinazione iniziale ospiterà 10 carichi di lavoro a scopo di apprendimento iniziale. Questi carichi di lavoro non sono fondamentali per l'azienda e non hanno accesso ai dati sensibili. In futuro, questi carichi di lavoro verranno probabilmente rilasciati in produzione, ma la criticità e la sensibilità non dovrebbero cambiare.
Per supportare questi carichi di lavoro, il team di adozione del cloud deve soddisfare i criteri seguenti:
- Segmentazione di rete per allinearsi alla progettazione di rete proposta. Questo ambiente deve essere una rete perimetrale con accesso a Internet pubblico.
- Accesso alle risorse di calcolo, archiviazione e rete per ospitare i carichi di lavoro allineati all'individuazione del patrimonio digitale.
- Denominazione e assegnazione di tag allo schema per semplificare l'uso.
- Durante l'adozione, al team di adozione del cloud viene concesso l'accesso temporaneo per modificare le configurazioni del servizio.
- Prima del rilascio in produzione, integrare con il provider di identità aziendale per la gestione continua dell'identità e dell'accesso nella gestione delle operazioni. A quel punto, l'accesso del team di adozione del cloud dovrebbe essere revocato.
L'ultimo punto non è un criterio di funzionalità o accettazione, ma un indicatore che saranno necessarie più espansioni e che devono essere esaminate con altri team in anticipo.
Esempi DoD più complessi
La metodologia Govern all'interno del Cloud Adoption Framework offre un viaggio narrativo attraverso la naturale maturazione di un team di governance. Incorporati in quel percorso sono diversi esempi di DoD e criteri di accettazione, sotto forma di dichiarazioni di politica.
dichiarazioni di politica iniziali. Esempio di DoD iniziale basato sui criteri aziendali che regolano i requisiti di adozione delle fasi iniziali.
Miglioramenti incrementali per espandere la gestione delle identità. Esempio di politiche aziendali che regolano il DoD per soddisfare i requisiti per espandere la gestione delle identità per una zona di atterraggio.
miglioramenti incrementali per ampliare i requisiti di sicurezza. Esempio di criteri aziendali che regolano DoD per soddisfare i requisiti di sicurezza allineati al piano di adozione del cloud di riferimento.
Miglioramenti incrementali per espandere la gestione operativa. Esempio di criteri aziendali che regolano DoD per soddisfare i requisiti di base di gestione delle operazioni.
miglioramenti incrementali per espandere la gestione dei costi. Esempio di criteri aziendali che regolano DoD per soddisfare i requisiti di gestione dei costi.
Gli esempi precedenti sono campioni semplici che ti aiutano a sviluppare un DoD per le zone di atterraggio.
Strumenti e funzionalità di Azure per supportare il TDD della zona di destinazione
Il diagramma seguente illustra gli strumenti di sviluppo basati su test disponibili in Azure:
È possibile integrare facilmente questi strumenti e funzionalità di Azure in TDD per la creazione della zona di destinazione. Gli strumenti servono obiettivi specifici, semplificando lo sviluppo, il test e la distribuzione delle landing zone conformemente ai cicli TDD.
Azure Resource Manager offre una piattaforma coerente per i processi di creazione e distribuzione. La piattaforma Resource Manager può distribuire zone di destinazione in base alle definizioni del codice sorgente.
I modelli di Azure Resource Manager (ARM) forniscono il codice sorgente principale per gli ambienti distribuiti in Azure. Alcuni strumenti di terze parti come Terraform forniscono modelli arm personalizzati da inviare ad Azure Resource Manager.
Modelli di Avvio Rapido di Azure forniscono modelli di codice sorgente che accelerano la distribuzione della zona di accoglienza e del carico di lavoro.
Azure Policy offre il meccanismo principale per testare i criteri di accettazione nel tuo DoD. Azure Policy può anche fornire rilevamento, protezione e risoluzione automatizzati quando le distribuzioni deviano dalle politiche di governance.
In un ciclo TDD è possibile creare una definizione di criteri per testare un singolo criterio di accettazione. I criteri di Azure includono definizioni di criteri predefinite che possono soddisfare i singoli requisiti di accettazione all'interno di un DoD. Questo approccio fornisce un meccanismo per i test rossi prima di modificare la zona di destinazione.
Azure Policy include anche iniziative di criteri predefinite che è possibile utilizzare per testare e applicare il DoD completo per una landing zone. È possibile aggiungere tutti i criteri di accettazione a un'iniziativa di criteri assegnata all'intera sottoscrizione. Una volta che la zona di atterraggio soddisfa il DoD, Azure Policy può far rispettare i criteri di test per evitare modifiche al codice che causerebbero l'esito negativo del test nelle versioni future.
Progettare ed esaminare Criteri di Azure come flussi di lavoro del codice come parte dell'approccio TDD.
Azure Resource Graph fornisce un linguaggio di query per la creazione di test guidati dai dati basati sulle informazioni sugli asset distribuiti in una landing zone. Più avanti nel piano di adozione, questo strumento può anche definire test complessi in base alle interazioni tra gli asset del carico di lavoro e l'ambiente cloud sottostante.
Resource Graph include esempi avanzati di query , che si possono usare per comprendere come i carichi di lavoro vengono distribuiti all'interno di un'area di atterraggio per scenari di test avanzati.
A seconda dell'approccio preferito, è anche possibile usare gli strumenti seguenti:
- Distribuire le zone di atterraggio usando Terraform.
- Distribuire le zone di atterraggio usando Bicep.
- Gestire le zone di destinazione usando AzOps, un modulo di PowerShell che esegue il push dei modelli di risorse e dei file Bicep a tutti i livelli di ambito di Azure ed esegue il pull e le esportazioni delle gerarchie di risorse di Azure.