Sviluppo basato sui 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 sul codice. TDD crea unit test case prima di sviluppare il codice effettivo e testa il codice rispetto ai test case. Questo approccio è contrario allo sviluppo del codice prima e alla creazione di test case in un secondo momento.
Una zona di destinazione è un ambiente per ospitare carichi di lavoro previsionati 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 distribuire zone di destinazione riuscite, soddisfando la qualità, la sicurezza, le operazioni e i requisiti di governance.
L'infrastruttura cloud è l'output dell'esecuzione del codice. Codice ben strutturato, testato e verificato produce una zona di destinazione attuabile. 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 le semplici richieste di funzionalità durante lo sviluppo anticipato. Più avanti nel ciclo di vita dell'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 zone di destinazione in un'attività di sviluppo parallela.
Ciclo di sviluppo basato su test
Il diagramma seguente illustra il ciclo di sviluppo basato sui test per le zone di destinazione di Azure:
Creare 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 sforzi di test manuali, in particolare per le distribuzioni su scala aziendale.
Testare la zona di destinazione. Eseguire il nuovo test e tutti i test esistenti. Se la funzionalità richiesta non è inclusa nelle offerte del provider di cloud e non è stata fornita dalle attività di sviluppo precedenti, il test deve avere esito negativo. L'esecuzione di test esistenti consente di verificare che la nuova funzionalità o il test non riduce l'affidabilità delle funzionalità della zona di destinazione esistente.
Espandere e eseguire il refactoring della zona di destinazione. Aggiungere o modificare il codice sorgente per soddisfare la funzionalità di aggiunta di valore richiesta e migliorare la qualità generale della code base.
Per soddisfare i criteri TDD, il team della piattaforma cloud aggiungerà codice solo per soddisfare la funzionalità richiesta. Tuttavia, la qualità del codice e la manutenzione sono sforzi condivisi. Man mano che soddisfano nuove richieste di funzionalità, il team della piattaforma cloud deve provare a migliorare il codice rimuovendo la duplicazione e chiarendo il codice. È consigliabile eseguire test tra la creazione di nuovo codice e il refactoring del codice sorgente.
Distribuire la zona di destinazione. Dopo aver soddisfatto la richiesta di funzionalità, distribuire la zona di destinazione modificata nel provider cloud in un ambiente di test o sandbox controllato.
Testare la zona di destinazione. Eseguire la rete della zona di destinazione 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 del completamento. Quando tutte le funzionalità a valore aggiunto e i criteri di accettazione superano i test associati, la zona di destinazione è pronta per supportare l'ondata successiva del piano di adozione del cloud.
Il ciclo che rende TDD efficace è spesso definito test rosso/verde. In questo approccio, il team della piattaforma cloud inizia con un test non riuscito o un test rosso, in base alla definizione del fatto e ai criteri di accettazione definiti. Per ogni funzionalità o criteri di accettazione, il team della piattaforma cloud completa le attività di sviluppo fino al passaggio del test o ha un test verde.
L'obiettivo di TDD è quello di affrontare meglio la progettazione, non creare una suite di test. I test sono un artefatto prezioso per completare il processo.
Definizione di completato
L'esito positivo può essere una misura soggettiva che fornisce un team della piattaforma cloud poco azionebile durante lo sviluppo o il refactoring della zona di destinazione. La mancanza di chiarezza può causare aspettative e vulnerabilità mancanti in un ambiente cloud. Prima che il team della piattaforma cloud refactors o espandi qualsiasi zona di destinazione, deve cercare chiarezza sulla definizione di doD (DoneD ) per ogni zona di destinazione.
DoD è un semplice accordo tra il team della piattaforma cloud e altri team interessati che definisce le funzionalità previste di aggiunta del valore da includere nel lavoro di sviluppo della zona di destinazione. Il DoD è spesso un elenco di controllo allineato al piano di adozione del cloud a breve termine.
Poiché 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 garantire maggiore chiarezza. Quando le funzionalità aggiunte a valore soddisfano tutti i criteri di accettazione, la zona di destinazione è sufficientemente configurata per consentire il successo dell'onda o del rilascio corrente dell'adozione.
Esempio DoD semplice
Per un'operazione di migrazione iniziale, il DoD potrebbe essere troppo semplice. L'esempio seguente è un DoD semplice:
La zona di destinazione iniziale ospiterà 10 carichi di lavoro per scopi iniziali di apprendimento. Questi carichi di lavoro non sono critici per l'azienda e non hanno accesso ai dati sensibili. In futuro, questi carichi di lavoro saranno probabilmente rilasciati alla produzione, ma la criticità e la riservatezza non sono previste modifiche.
Per supportare questi carichi di lavoro, il team di adozione del cloud deve soddisfare i criteri seguenti:
- Segmentazione a livello di rete da allineare 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 digital estate.
- Schema di denominazione e assegnazione di tag per facilità d'uso.
- Durante l'adozione, l'accesso temporaneo per il team di adozione del cloud modifica le configurazioni del servizio.
- Prima della versione di produzione, l'integrazione con il provider di identità aziendale per gestire l'identità continua e l'accesso per la gestione delle operazioni. In quel momento, l'accesso del team di adozione del cloud deve essere revocato.
L'ultimo punto non è un criterio di accettazione o di funzionalità, ma un indicatore che saranno necessarie altre espansioni e che devono essere esaminate con altri team in anticipo.
Esempi DoD più complessi
La metodologia di governance nell'ambito di Cloud Adoption Framework offre un percorso narrativo attraverso la naturale maturità di un team di governance. Incorporato in tale percorso sono diversi esempi di criteri di doD e accettazione, sotto forma di istruzioni dei criteri.
Istruzioni di criteri iniziali. Esempio di DoD iniziale basato sui criteri aziendali che regolano i requisiti di adozione in fase iniziale.
Miglioramenti incrementali per espandere gestione delle identità. Esempio di criteri aziendali che regolano DoD per soddisfare i requisiti per espandere la gestione delle identità per una zona di destinazione.
Miglioramenti incrementali per espandere 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 delle operazioni. Esempio di criteri aziendali che regolano DoD per soddisfare i requisiti di gestione delle operazioni di base.
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 esempi di base che consentono di sviluppare un DoD per le zone di destinazione. È possibile ottenere criteri di esempio per ognuna delle cinque discipline della governance cloud.
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 scopi specifici, semplificando lo sviluppo, il test e la distribuzione di zone di destinazione in allineamento con cicli TDD.
Azure Resource Manager offre una piattaforma coerente per i processi di compilazione 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 codice sorgente primario per gli ambienti distribuiti in Azure. Alcuni strumenti di terze parti, ad esempio Terraform, forniscono modelli di Resource Manager personalizzati da inviare ad Azure Resource Manager.
I modelli di avvio rapido di Azure forniscono modelli di codice sorgente che consentono di accelerare la distribuzione della zona di destinazione e del carico di lavoro.
Criteri di Azure fornisce il meccanismo principale per testare i criteri di accettazione nel DoD. Criteri di Azure può anche fornire rilevamento, protezione e risoluzione automatizzati quando le distribuzioni deviano dai criteri di governance.
In un ciclo TDD è possibile creare una definizione di criteri per testare un singolo criterio di accettazione. Criteri di Azure include definizioni di criteri predefiniti che possono soddisfare i singoli criteri di accettazione all'interno di un DoD. Questo approccio fornisce un meccanismo per i test rossi prima di modificare la zona di destinazione.
Criteri di Azure include anche iniziative di criteri predefinite che è possibile usare per testare e applicare il DoD completo per una zona di destinazione. È possibile aggiungere tutti i criteri di accettazione a un'iniziativa di criteri assegnata all'intera sottoscrizione. Una volta che la zona di destinazione soddisfa il DoD, Criteri di Azure può applicare i criteri di test per evitare modifiche al codice che causerebbero l'esito negativo del test nelle versioni future.
Progettare e esaminare Criteri di Azure come flussi di lavoro del codice come parte dell'approccio TDD.
Criteri di gruppi di Azure Blueprints e altri strumenti di distribuzione in un pacchetto ripetibile che è possibile assegnare a più zone di destinazione. I progetti sono utili per più sforzi di adozione che condividono doD comuni, che potrebbero essere utili per l'aggiornamento nel tempo. Azure Blueprints può anche essere utile per la distribuzione durante gli sforzi successivi per espandere e refactorare le zone di destinazione.
Azure Blueprints fornisce vari esempi di progetto, inclusi i criteri per i test e i modelli per la distribuzione. Questi esempi di progetto possono accelerare le attività di sviluppo, distribuzione e test nei cicli TDD.
Azure Resource Graph fornisce un linguaggio di query per la creazione di test basati sui dati in base alle informazioni sugli asset distribuiti in una zona di destinazione. Nelle fasi successive del 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 di query avanzati, che è possibile usare per comprendere il modo in cui i carichi di lavoro vengono distribuiti all'interno di una zona di destinazione per scenari di test avanzati.
A seconda dell'approccio preferito, è anche possibile usare gli strumenti seguenti:
- Distribuire zone di destinazione usando Terraform.
- Distribuire le zone di destinazione 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 e esegue il pull e esporta le gerarchie delle risorse di Azure.