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 zona di destinazione è un ambiente per l'hosting di carichi di lavoro di cui viene 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 distribuire zone di destinazione riuscite rispettando i requisiti di qualità, sicurezza, operazioni e 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 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 zone di destinazione in uno sforzo 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:
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 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 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 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 destinazione. Dopo che il codice sorgente soddisfa la richiesta di funzionalità, distribuire la zona di destinazione modificata al provider di servizi cloud in un ambiente di test controllato o sandbox.
Testare la zona di destinazione. Eseguire di nuovo 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 di completato. 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 efficace il TDD viene 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 di fatto 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 di completato
Il successo può essere una misura soggettiva che fornisce a un team della piattaforma cloud informazioni poco interattive 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 esebri il refactoring o espandi le zone di destinazione, deve cercare chiarezza riguardo alla 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à a valore aggiunto previste 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.
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à aggiunte a valore soddisfano tutti i criteri di accettazione, la zona di destinazione è sufficientemente configurata per consentire il successo dell'attuale onda 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 nell'ambiente di produzione, ma la criticità e la riservatezza non dovrebbero cambiare.
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 del rilascio di produzione, l'integrazione con il provider di identità aziendale per gestire l'identità e l'accesso continui 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 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 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 accettazione e DoD, sotto forma di istruzioni dei criteri.
Istruzioni dei criteri 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 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 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 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 del 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 delle zone di destinazione in allineamento con i 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 il codice sorgente primario per gli ambienti distribuiti in Azure. Alcuni strumenti di terze parti come Terraform forniscono modelli arm 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 si discostono 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 causano l'esito negativo del test nelle versioni future.
Progettare ed esaminare Criteri di Azure come flussi di lavoro di codice come parte dell'approccio TDD.
Azure Resource Graph offre 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 come vengono distribuiti i carichi di lavoro all'interno di una zona di destinazione per scenari di test avanzati.
A seconda dell'approccio preferito, è anche possibile usare gli strumenti seguenti:
- Distribuire le 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 ed esegue il pull e le esportazioni delle gerarchie di risorse di Azure.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per