Suggerimenti per la progettazione di una supply chain di sviluppo del carico di lavoro

Si applica a questa raccomandazione per l'eccellenza operativa di Azure Well-Architected Framework:

Questa guida descrive le raccomandazioni per la progettazione di una supply chain di sviluppo di carichi di lavoro basata su pipeline di integrazione continua e recapito continuo (CI/CD). Sviluppare una catena di approvvigionamento per assicurarsi di avere un metodo prevedibile e standardizzato per gestire il carico di lavoro. Le pipeline CI/CD sono la manifestazione della catena di approvvigionamento, ma è necessario avere una singola catena di approvvigionamento. Inoltre, potrebbero essere presenti diverse pipeline che seguono gli stessi processi e usano gli stessi strumenti.

Incorporare una supply chain per proteggere il carico di lavoro da danni che possono verificarsi quando non si gestiscono correttamente le modifiche del carico di lavoro. Tenere sempre presente lo stato del carico di lavoro, quindi non si è a rischio di riscontrare un comportamento imprevedibile. Questo rischio si somma se è necessario dedicare tempo critico a ritracciare le modifiche non rilevate quando si verificano problemi. Per ridurre al minimo questi rischi, standardizzare i processi e gli strumenti che definiscono la supply chain e assicurarsi che il team del carico di lavoro si impegni completamente all'uso.

Definizione

Strategie di progettazione chiave

Le raccomandazioni seguenti consentono di definire i set di base della supply chain.

Applicare un criterio rigoroso delle distribuzioni automatizzate basate su modelli

Apportare modifiche al carico di lavoro proposte tramite processi e strumenti della supply chain. Applicare un criterio rigoroso delle distribuzioni automatizzate basate su modelli. Questo metodo consente di garantire che la configurazione del carico di lavoro in tutti gli ambienti sia standardizzata, ben definita e strettamente controllata. Per gli ambienti in una catena di promozioni del codice, non eseguire gli aggiornamenti usando processi manuali o interazione umana con il piano di controllo della piattaforma cloud, ad esempio il portale o un'API. Incorporare tutte le modifiche all'ambiente tramite una pipeline seguendo le procedure di distribuzione definite dall'utente. Per applicare questo criterio, è consigliabile limitare l'accesso in sola lettura come impostazione predefinita e usare un controllo di autorizzazione di accesso per consentire l'accesso in scrittura.

Un aspetto importante di questa tenet è che tutte le modifiche vengono proposte fino a quando non vengono distribuite nell'ambiente di produzione. Tramite test automatizzati, come l'integrazione e i test di fumo, è possibile consentire alla supply chain di rifiutare automaticamente le modifiche.

Distribuire un'infrastruttura ripetibile e non modificabile come codice

Distribuire un'infrastruttura ripetibile e non modificabile come codice (IaC). IaC consiste nella gestione dell'infrastruttura in un modello descrittivo che usa un sistema di controllo delle versioni che rispecchia il codice sorgente. Quando si crea un'applicazione, lo stesso codice sorgente può generare lo stesso binario ogni volta che viene compilato. Analogamente, un modello di infrastruttura come codice genera lo stesso ambiente ogni volta che viene applicato.

Incorporare IaC per assicurarsi che il team segua un processo standard e ben stabilito. Alcune organizzazioni designano un singolo o piccolo gruppo di utenti per distribuire e configurare l'infrastruttura. Quando si implementa un processo completamente automatizzato, le distribuzioni dell'infrastruttura richiedono una gestione minore da parte degli utenti. La responsabilità viene trasferita al processo di automazione e agli strumenti. I membri del team possono avviare distribuzioni dell'infrastruttura per mantenere la coerenza e la qualità.

Progettare il carico di lavoro come un gruppo logico di componenti che è possibile aggregare in un unico modello per semplificare e ripetere le distribuzioni. È possibile pensare a questi bundle come timbri o unità di scala. Per altre informazioni, vedere Modello stamp di distribuzione. Quando è necessario distribuire il carico di lavoro per aumentare il numero di istanze in un'altra area o zona all'interno della stessa area, distribuire un timbro usando una pipeline. A seconda del modo in cui si progettano i timbri, è possibile distribuire un subset del carico di lavoro anziché l'intero carico di lavoro. Includere i componenti di rete nelle pipeline IaC per assicurarsi che i moduli di distribuzione si connettano automaticamente alle risorse esistenti.

Per ottimizzare la pipeline IaC per coerenza ed efficienza, progettare un'infrastruttura non modificabile anziché un'infrastruttura modificabile. Implementare un'infrastruttura non modificabile per garantire che tutti i sistemi nell'ambito vengano sostituiti con la configurazione aggiornata contemporaneamente e in modo identico a ogni distribuzione.

Usare lo stesso set di artefatti di distribuzione in tutti gli ambienti

Usare un set di asset di codice e artefatti in tutti gli ambienti e le pipeline. Un punto critico comune per le organizzazioni è rappresentato dalla differenza tra gli ambienti non di produzione e quelli di produzione. La compilazione manuale degli ambienti di produzione e di quelli non di produzione può comportare configurazioni non corrispondenti tra gli ambienti. Questa mancata corrispondenza rallenta i test e rende più probabile che le modifiche possano danneggiare un sistema di produzione. Un approccio IaC riduce al minimo questi problemi. Quando si usa l'automazione IaC, è possibile usare gli stessi file di configurazione dell'infrastruttura per tutti gli ambienti per produrre ambienti quasi identici. È possibile aggiungere parametri ai file di configurazione dell'infrastruttura e modificarli per soddisfare i requisiti per ogni ambiente.

Per controllare i costi, si verifica in genere una varianza tra ambienti di produzione e non di produzione. Spesso non è necessario lo stesso grado di ridondanza e prestazioni in ambienti non di produzione sufficienti nell'ambiente di produzione. Il numero e lo SKU delle risorse possono variare tra gli ambienti. Assicurarsi di controllare e comprendere la varianza usando parametri standardizzati per mantenere la prevedibilità man mano che si apportano modifiche.

Riflettere la struttura organizzativa nella supply chain

Riflettere la struttura organizzativa nelle progettazioni della supply chain e della pipeline. L'organizzazione potrebbe essere allineata tra i team. Ogni team può gestire una parte della supply chain. Ad esempio, molte organizzazioni dispongono di team che gestiscono domini dell'infrastruttura, ad esempio rete, dati e risorse di calcolo. Questi team sono separati dai team di sviluppo che gestiscono lo sviluppo, il test e le distribuzioni delle applicazioni. In alcune organizzazioni, i team di sviluppo e infrastruttura sono incorporati nei team DevOps che gestiscono collettivamente tutte le distribuzioni di infrastruttura e applicazioni. Esistono molti modi per organizzare i team coinvolti in una supply chain. La catena di fornitura si basa su tutti i team che collaborano senza problemi. Assicurarsi che tutti i team seguano i processi standard e usino gli strumenti standard per rendere la supply chain il più efficiente possibile.

La supply chain può basarsi su fornitori di terze parti se si esternalizzano parti del ciclo di vita del carico di lavoro. Questi fornitori sono altrettanto importanti per il successo della supply chain come le risorse interne. Assicurarsi che sia presente un accordo reciproco tra tutti i team relativi ai processi e agli strumenti usati.

Scegliere il metodo di distribuzione corretto

Standardizzare il metodo di distribuzione. Rivolgersi al produttore per stabilire la quantità accettabile di tempo di inattività della produzione per il carico di lavoro. A seconda di quanto sia accettabile il tempo di inattività, è possibile scegliere il metodo di distribuzione più adatto alle proprie esigenze. Idealmente, è consigliabile eseguire distribuzioni durante una finestra di manutenzione per ridurre la complessità e il rischio. Se non è accettabile alcun tempo di inattività, usare un metodo di distribuzione blu-verde.

Usare un approccio di esposizione progressiva per ridurre il rischio di introdurre bug non rilevati ai clienti in generale. Noto anche come distribuzioni canary, questo metodo viene distribuito in gruppi controllati di utenti in una sequenza graduale. Rileva i problemi prima che influiscano su più utenti. Il gruppo di implementazione iniziale potrebbe essere una sottosezione dei clienti che conoscono la strategia di implementazione. Questa sottosezione dei clienti può tollerare una certa quantità di comportamenti imprevisti e fornire feedback. Oppure potrebbe essere un gruppo di utenti interni, che aiuta a contenere il raggio di esplosione di bug durante l'implementazione.

Quando si definisce il metodo di distribuzione, adottare un criterio standard per distribuire solo la minima modifica praticabile in ogni distribuzione. A seconda di fattori come la criticità del carico di lavoro e della complessità dei componenti, determinare la modifica praticabile più piccola. Se si usa un'infrastruttura non modificabile, la modifica praticabile più piccola è in genere la distribuzione delle risorse con la configurazione più recente per sostituire le risorse che eseguono la versione precedente. Se si usa un'infrastruttura modificabile, è possibile decidere che la modifica più piccola valida è solo un singolo aggiornamento nel gruppo di risorse nell'ambito.

Seguire un approccio a più livelli

Seguire un approccio a più livelli per riflettere i diversi cicli di vita. I livelli di base devono rimanere statici per la maggior parte del ciclo di vita del carico di lavoro, mentre i livelli dell'applicazione cambiano frequentemente. Per tenere conto di queste differenze, è necessario disporre di pipeline diverse per apportare modifiche a ogni livello.

Una zona di destinazione è al livello più basso. Una zona di destinazione è un raggruppamento logico di elementi fondamentali, ad esempio sottoscrizioni, gruppi di gestione, gruppi di risorse, funzioni di governance e topologia di rete. Una zona di destinazione consente di distribuire e gestire facilmente il carico di lavoro e di fornire team operativi centrali o team della piattaforma con un approccio ripetibile a una configurazione ambientale. Per offrire ambienti coerenti, tutte le zone di destinazione di Azure forniscono un set di aree di progettazione comuni, un'architettura di riferimento, un'implementazione di riferimento e un processo per modificare una distribuzione in base ai requisiti di progettazione. I principi di progettazione della zona di destinazione di Azure forniscono procedure consigliate basate sulla governance basata su criteri insieme alla democratizzazione delle sottoscrizioni. Una zona di destinazione deve richiedere modifiche minime nel corso del ciclo di vita del carico di lavoro. Per un esempio di zona di destinazione, vedere Che cos'è una zona di destinazione di Azure. Questa architettura concettuale fornisce un set di opinioni consigliate per Azure.

L'infrastruttura e le funzioni principali, come i controller di rete in ingresso e in uscita, il bilanciamento del carico, le soluzioni di routing di rete, la gestione DNS e i server principali, devono anche richiedere modifiche importanti poco frequenti. Tuttavia, potrebbero richiedere aggiornamenti frequenti della configurazione.

L'applicazione e il livello dati richiedono aggiornamenti frequenti della configurazione e modifiche frequenti dell'infrastruttura. Questi componenti devono avere le pipeline più dinamiche.

Incorporare tipi completi di test

Pianificare una strategia di test olistica. Un elemento fondamentale dell'affidabilità del sistema è il principio di spostamento a sinistra . Lo sviluppo e la distribuzione di un'applicazione è un processo illustrato come una serie di passaggi che vanno da sinistra a destra. Non è consigliabile limitare i test alla fine del processo. Il più possibile, spostare i test all'inizio o a sinistra. Gli errori sono più economici da riparare quando li si intercetta in anticipo. Possono essere costosi o impossibili da correggere in un secondo momento nel ciclo di vita dell'applicazione.

Testare tutto il codice, inclusi il codice dell'applicazione, i modelli di infrastruttura e gli script di configurazione. L'ambiente che esegue le applicazioni deve essere controllato dalla versione e distribuito tramite gli stessi meccanismi del codice dell'applicazione. È possibile testare e convalidare l'ambiente usando gli stessi paradigmi di test già usati dai team per il codice dell'applicazione.

Quando possibile, usare test automatizzati per garantire la coerenza. Includere i tipi di test seguenti nella progettazione della supply chain.

• Unit test: gli unit test vengono in genere eseguiti come parte di una routine di integrazione continua. Gli unit test devono essere estesi e rapidi. Dovrebbero idealmente coprire il 100% del codice ed essere eseguiti in meno di 30 secondi.

  Implementare unit test per verificare che la sintassi e le funzionalità dei singoli moduli di codice funzionino nel modo in cui devono, ad esempio, produrre un output definito per un input noto. È anche possibile usare unit test per verificare che gli asset IaC siano validi.

  Applicare unit test a tutti gli asset di codice, inclusi modelli e script.

• Test di fumo: i test smoke verificano che un carico di lavoro possa essere alzato in un ambiente di test ed eseguito come previsto. I test smoke non verificano l'interoperabilità dei componenti.

  I smoke test verificano che la metodologia di distribuzione per l'infrastruttura e l'applicazione funzioni e che il sistema risponda come previsto al termine del processo.

• Test di integrazione: i test di integrazione assicurano che i componenti dell'applicazione funzionino singolarmente e quindi determinano se i componenti possono interagire tra loro come dovrebbero.

  L'esecuzione di un gruppo di test di integrazione di grandi dimensioni può richiedere molto tempo. Ecco perché è consigliabile incorporare il principio di spostamento a sinistra ed eseguire test all'inizio del ciclo di vita dello sviluppo software. Riservare test di integrazione per scenari che non è possibile testare con uno smoke test o unit test.

  Se necessario, è possibile eseguire processi di test a esecuzione prolungata a intervalli regolari. Un intervallo regolare offre un buon compromesso e rileva problemi di interoperabilità tra i componenti dell'applicazione non più tardi di un giorno dopo l'introduzione.

  Alcuni scenari di test traggono vantaggio dalle esecuzioni manuali. Usare test manuali quando è necessario introdurre elementi di interattività umana nei test.

• Test di accettazione: a seconda del contesto, è possibile eseguire manualmente test di accettazione. Può essere parzialmente o completamente automatizzato. I test di accettazione determinano se il sistema software soddisfa le specifiche dei requisiti.

  Lo scopo principale di questo test è valutare la conformità del sistema ai requisiti aziendali e determinare se il sistema soddisfa i criteri necessari per il recapito agli utenti finali.

Implementare controlli di qualità nei processi di promozione del codice

Implementare controlli di qualità durante il processo di promozione del codice tramite test. Distribuire il codice in ambienti inferiori, ad esempio sviluppo e test, e fino a ambienti più elevati, ad esempio staging e produzione. Quando la distribuzione passa attraverso controlli di qualità, assicurarsi che soddisfi gli obiettivi di qualità prima che le modifiche passino all'ambiente di produzione. I requisiti aziendali determinano l'obiettivo dei controlli di qualità. Considerare anche i principi fondamentali del framework ben progettato: sicurezza, affidabilità ed efficienza delle prestazioni.

Integrare anche i flussi di lavoro di approvazione nei controlli di qualità. Definire e automatizzare chiaramente i flussi di lavoro di approvazione quando appropriato. Definire criteri di accettazione della qualità nell'automazione, in modo da poter passare attraverso i cancelli in modo efficiente e sicuro.

Facilitazione di Azure

Azure DevOps è una raccolta di servizi che consentono di creare una pratica di sviluppo collaborativa, efficiente e coerente.

Azure Pipelines offre servizi di compilazione e rilascio per supportare CI/CD nelle applicazioni.

GitHub Actions per Azure si integra con Azure per semplificare le distribuzioni. Usare GitHub Actions per automatizzare i processi CI/CD. È possibile creare flussi di lavoro che compilano e testano ogni richiesta pull nel repository o distribuiscono richieste pull unite nell'ambiente di produzione.

È possibile usare Terraform, Bicep e Azure Resource Manager per le distribuzioni IaC. A seconda dei requisiti e della familiarità del team con gli strumenti, è possibile usare uno o più di questi strumenti per le distribuzioni e la gestione delle risorse.

Esempio

Per un esempio che illustra come usare Azure Pipelines per creare una pipeline CI/CD, vedere Architettura di base di Azure Pipelines.

Collegamenti correlati

• Azure DevOps
• Azure Pipelines
• Modello degli stamp di distribuzione
• GitHub Actions per Azure
• Pilastro dell'efficienza delle prestazioni
• Pilastro dell'affidabilità
• Pilastro della sicurezza

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.