Share via

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

  • Articolo

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

OE:06 Creare una supply chain del carico di lavoro che guida le modifiche proposte tramite pipeline prevedibili e automatizzate. Le pipeline testano e alzano di livello tali modifiche tra ambienti. Ottimizzare una supply chain per rendere il carico di lavoro affidabile, sicuro, conveniente ed efficiente.

Questa guida descrive le raccomandazioni per la progettazione di una supply chain di sviluppo del carico di lavoro basata su pipeline di integrazione continua e recapito continuo (CI/CD). Sviluppare una supply chain per assicurarsi di avere un metodo prevedibile e standardizzato per gestire il carico di lavoro. Le pipeline CI/CD sono la manifestazione della supply chain, ma è necessario avere una singola supply chain. E 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 rischia di riscontrare comportamenti imprevedibili. Questo rischio è composto se è necessario dedicare tempo critico a ritracciare le modifiche non rilevate in caso di 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 nell'uso.

Definition

Termine Definizione
Catena di fornitura Nei carichi di lavoro cloud, una supply chain è una suite standardizzata di strumenti e processi usati per influire sul cambiamento dell'infrastruttura e delle applicazioni tra ambienti.

Strategie di progettazione chiave

Nota

Le raccomandazioni contenute in questa guida fanno riferimento agli ambienti del carico di lavoro in una catena di promozioni del codice. Sandbox o altri ambienti esplorativi e di prova richiedono meno rigore e struttura.

Set di base

Le raccomandazioni seguenti consentono di definire i principi fondamentali della supply chain.

Apportare modifiche al carico di lavoro proposte tramite processi e strumenti della supply chain. Applicare un criterio rigoroso di 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 controllata in modo rigoroso. Per gli ambienti in una catena di promozione del codice, non eseguire 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 questo tenet è che tutte le modifiche vengono propostemodifiche fino a quando non vengono distribuite nell'ambiente di produzione. Tramite test automatizzati, ad esempio l'integrazione e i test di fumo, si abilita la supply chain per rifiutare automaticamente le modifiche.

Distribuire un'infrastruttura ripetibile e non modificabile come codice (IaC). IaC è la 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 deve generare lo stesso file 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 garantire che il team segua un processo standard e ben stabilito. Alcune organizzazioni designano un singolo 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 gruppo logico di componenti che è possibile aggregare in un 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 gli indicatori, è 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 un set di asset di codice e artefatti in tutti gli ambienti e le pipeline. Un punto di difficoltà comune per le organizzazioni è quando gli ambienti non di produzione sono diversi dagli ambienti di produzione. La creazione manuale di ambienti di produzione e 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 sono necessari gli stessi livelli di ridondanza e prestazioni in ambienti non 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 nelle progettazioni della supply chain e della pipeline. L'organizzazione potrebbe essere siloata tra i team. Ogni team può gestire una parte della supply chain. Ad esempio, molte organizzazioni hanno team che gestiscono domini di 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 di applicazioni. In alcune organizzazioni, i team di sviluppo e infrastruttura vengono 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 supply chain si basa su tutti i team che lavorano perfettamente insieme. Assicurarsi che tutti i team seguano i processi standard e usino 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 critici per il successo della supply chain come risorse interne. Assicurarsi che sia presente un accordo reciproco tra tutti i team relativi ai processi e agli strumenti usati.

Standardizzare il metodo di distribuzione. Rivolgersi al proprietario del prodotto sulla quantità accettabile di tempo di inattività di produzione per il carico di lavoro. A seconda di quanto, se presente, il tempo di inattività è accettabile, è 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 i rischi. Se non è accettabile un 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 a 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 comportamento imprevisto 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 che consente di 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 più piccola praticabile. Se si usa un'infrastruttura non modificabile, la modifica più piccola valida è 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 del gruppo di risorse nell'ambito.

Seguire un approccio a più livelli per riflettere i diversi cicli di vita. I livelli fondamentali devono rimanere statici nella maggior parte del ciclo di vita del carico di lavoro e i livelli dell'applicazione cambiano frequentemente. Per tenere conto di queste differenze, è necessario avere pipeline diverse per rendere effettive le 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, ad esempio 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. Potrebbero tuttavia essere necessari aggiornamenti frequenti della configurazione.

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

Pianificare una strategia di test olistica. Un principio 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 per la riparazione quando vengono catturati 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 la 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.

  • Smoke testing: i test smoke verificano che un carico di lavoro possa essere alzato in un ambiente di test ed eseguito come previsto. I smoke test 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 i test di integrazione per gli 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 una buona compromissione 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 i 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à 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 gestione temporanea e produzione. Man mano che 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 qual è l'obiettivo dei controlli di qualità. Considerare anche i principi fondamentali del framework di Well-Architected: 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 versione 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.

Elenco di controllo per l'eccellenza delle operazioni

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa