Condividi tramite

Architettura di base CI/CD con Azure Pipelines

  • Articolo

Questo articolo descrive un flusso di lavoro DevOps di alto livello per la distribuzione delle modifiche dell'applicazione negli ambienti di gestione temporanea e produzione in Azure. La soluzione usa procedure di integrazione continua/distribuzione continua (CI/CD) con Azure Pipelines.

Importante

Questo articolo illustra un'architettura CI/CD generale con Azure Pipelines. Non è progettato per coprire le specifiche della distribuzione in ambienti diversi, ad esempio Servizi app di Azure, Macchine virtuali e Azure Power Platform. Le specifiche della piattaforma di distribuzione sono descritte in articoli separati.

Architettura

diagramma dell'architettura di una pipeline CI/CD con Azure Pipelines.

Scarica un file Visio di questa architettura.

Nota

Anche se questo articolo illustra CI/CD per le modifiche delle applicazioni, Azure Pipelines può essere usato anche per creare pipeline CI/CD per le modifiche all'infrastruttura come codice (IaC).

Flusso di dati

I dati passano attraverso lo scenario come segue:

  1. pipeline di PR - Una pull request (PR) su Azure Repos Git attiva una pipeline di PR. Questa pipeline esegue rapidi controlli di qualità. Questi controlli devono includere:

    • Compilazione del codice, che richiede di scaricare le dipendenze da un sistema di gestione delle dipendenze.
    • Uso di strumenti per analizzare il codice, ad esempio analisi statica del codice, linting e analisi della sicurezza
    • Test unità

    Se uno dei controlli ha esito negativo, l'esecuzione della pipeline termina e lo sviluppatore dovrà apportare le modifiche necessarie. Se tutti i controlli vengono superati, la pipeline dovrebbe richiedere una revisione della pull request. Se la revisione della pull request ha esito negativo, la pipeline termina e lo sviluppatore dovrà apportare le modifiche necessarie. Se vengono superati tutti i controlli e le revisioni delle pull request, la pull request sarà unita con successo.

  2. pipeline CI - Un merge in Azure Repos Git attiva una pipeline CI. Questa pipeline esegue i medesimi controlli della pipeline PR, con anche alcune aggiunte importanti. La pipeline CI esegue test di integrazione. I test di integrazione possono essere a elevato utilizzo di risorse, quindi l'esecuzione nella pipeline CI bilancia la velocità di sviluppo e il rilevamento di bug. È anche importante notare che il superamento dei test in una pull request non garantisce sempre che abbiano esito positivo dopo la fusione, poiché le modifiche nel ramo principale possono introdurre nuovi problemi, evidenziando la necessità di test post-fusione. Questi fattori rendono la pipeline CI un posto migliore per i test di integrazione rispetto alla pipeline PR. Questi test di integrazione non devono richiedere la distribuzione della soluzione, perché gli artefatti di compilazione non sono ancora stati creati. Se i test di integrazione richiedono segreti, la pipeline ottiene tali segreti da Azure Key Vault. Se uno dei controlli ha esito negativo, la pipeline termina e lo sviluppatore dovrà apportare le modifiche necessarie. Il risultato di un'esecuzione corretta di questa pipeline è la creazione e la pubblicazione di artifatti di build.

  3. il trigger della pipeline CD: la pubblicazione di elementi attiva la pipeline CD.

  4. Rilascio CD a staging: La pipeline CD scarica gli artefatti di build creati nella pipeline CI e distribuisce la soluzione in un ambiente di staging. La pipeline esegue quindi test di accettazione sull'ambiente di staging per convalidare la distribuzione. Se un test di accettazione ha esito negativo, la pipeline termina e lo sviluppatore dovrà apportare le modifiche necessarie. Se i test hanno esito positivo, è possibile implementare un'attività di convalida manuale per richiedere a una persona o a un gruppo di convalidare la distribuzione e riprendere la pipeline.

  5. Rilascio in produzione del CD alla - Se l'intervento manuale viene continuato o non è implementato alcun intervento manuale, la pipeline rilascia la soluzione nell'ambiente di produzione. La pipeline deve eseguire smoke test nell'ambiente di produzione per assicurarsi che il rilascio funzioni come previsto. Se un passaggio di intervento manuale risulta in un annullamento, la release fallisce o i test preliminari falliscono, viene eseguito il rollback della release, la pipeline termina e lo sviluppatore dovrà apportare le modifiche necessarie.

  6. Monitoraggio - Azure Monitor raccoglie dati di osservabilità, ad esempio log e metriche, in modo che un operatore possa analizzare i dati di stato, prestazioni e utilizzo. Application Insights raccoglie tutti i dati di monitoraggio specifici dell'applicazione, ad esempio le tracce. Azure Log Analytics viene usato per archiviare tutti i dati.

Componenti

  • Un repository Git Azure Repos funge da repository di codice che fornisce il controllo della versione e una piattaforma per i progetti collaborativi.

  • azure Pipelines consente di compilare, testare, creare pacchetti e rilasciare codice dell'applicazione e dell'infrastruttura. Questo esempio ha tre pipeline distinte con le responsabilità seguenti:

    • Le pipeline di pull request convalida il codice prima di consentire a una richiesta pull di eseguire il merge tramite linting, compilazione e unit test.
    • Le pipeline CI vengono eseguite dopo il merge del codice. Eseguono la stessa convalida delle pipeline di pull request, ma aggiungono test di integrazione e pubblicano artefatti di compilazione se tutto va a buon fine.
    • Le pipeline CD distribuiscono gli artefatti di build, eseguono test di accettazione e rilasciano in produzione.

  • i feed degli artefatti di Azure consentono di gestire e condividere pacchetti software, ad esempio Maven, npm e NuGet. I feed di artefatti consentono di gestire il ciclo di vita dei pacchetti, inclusi il versionamento, la promozione e il ritiro dei pacchetti. Ciò consente di assicurarsi che il team usi le versioni più recenti e sicure dei pacchetti.

  • key vault consente di gestire i dati sicuri per la soluzione, inclusi segreti, chiavi di crittografia e certificati. In questa architettura viene usato per archiviare i segreti dell'applicazione. Questi segreti sono accessibili tramite la pipeline. È possibile accedere ai segreti da Azure Pipelines mediante un'attività Key Vault o collegando segreti dal Key Vault.

  • Monitor è una risorsa di osservabilità che raccoglie e memorizza metriche e log, la telemetria delle applicazioni e le metriche della piattaforma per i servizi di Azure. Usare questi dati per monitorare l'applicazione, configurare avvisi, dashboard ed eseguire l'analisi della causa radice degli errori.

  • Application Insights è un servizio di monitoraggio che fornisce informazioni dettagliate in tempo reale sulle prestazioni e sull'utilizzo delle applicazioni Web.

  • 'area di lavoro Log Analytics offre una posizione centrale in cui è possibile archiviare, eseguire query e analizzare i dati da più origini, tra cui risorse, applicazioni e servizi di Azure.

Alternative

Anche se questo articolo è incentrato su Azure Pipelines, è possibile prendere in considerazione queste alternative:

  • Azure DevOps Server può essere usato come alternativa on-premise.

  • Jenkins è uno strumento open source usato per automatizzare compilazioni e distribuzioni.

  • GitHub Actions consente di automatizzare i flussi di lavoro CI/CD direttamente da GitHub.

  • repository GitHub possono essere sostituiti come repository di codice. Azure Pipelines si integra perfettamente con i repository GitHub.

Questo articolo è incentrato sulle pratiche generali di CI/CD con Azure Pipelines. Di seguito sono riportati alcuni ambienti di calcolo in cui è possibile prendere in considerazione la distribuzione:

  • Il Servizio App è un servizio basato su HTTP per l'hosting di applicazioni web, API REST e back-end mobili. È possibile sviluppare nel linguaggio preferito e le applicazioni vengono eseguite e ridimensionate con facilità in ambienti basati su Windows e Linux. Le App Web supportano slot di distribuzione come staging e produzione. È possibile distribuire un'applicazione in uno slot di staging e rilasciarla nello slot di produzione.

  • macchine virtuali di Azure gestisce i carichi di lavoro che richiedono un livello elevato di controllo o dipendono da componenti e servizi del sistema operativo non possibili con app Web.

  • azure Power Platform è una raccolta di servizi cloud che consentono agli utenti di creare, distribuire e gestire applicazioni senza la necessità di infrastruttura o competenze tecniche.

  • Funzioni di Azure è una piattaforma di calcolo serverless che è possibile usare per sviluppare applicazioni. Con Funzioni è possibile usare trigger e associazioni per integrare i servizi. Le funzioni supportano anche slot di distribuzione come staging e produzione. È possibile distribuire un'applicazione in uno slot di staging e rilasciarla nello slot di produzione.

  • Azure Kubernetes Service (AKS) è un cluster Kubernetes gestito in Azure. Kubernetes è una piattaforma di orchestrazione dei contenitori open source.

  • Azure Container Apps consente di eseguire applicazioni containerizzate su una piattaforma serverless.

Dettagli dello scenario

L'uso di procedure CI e CD comprovate per distribuire le modifiche all'applicazione o all'infrastruttura offre diversi vantaggi, tra cui:

  • cicli di rilascio più brevi: i processi CI/CD automatizzati consentono di distribuire più velocemente rispetto alle procedure manuali. Molte organizzazioni distribuiscono più volte al giorno.
  • Migliore qualità del codice - Controlli di qualità nelle pipeline CI, ad esempio linting e unit test, generano codice di qualità superiore.
  • Riduzione del rischio di rilascio di : le procedure CI/CD appropriate riducono drasticamente il rischio di rilasciare nuove funzionalità. La distribuzione può essere testata prima del rilascio.
  • Maggiore produttività - Il CI/CD automatizzato libera gli sviluppatori dal lavoro su integrazioni e distribuzioni manuali così che possano concentrarsi sulle nuove funzionalità.
  • Abilitare i rollback- Sebbene le procedure CI/CD appropriate diminuiscano il numero di bug o regressioni rilasciate, si verificano ancora. CI/CD può abilitare i rollback automatici alle versioni precedenti.

Casi d'uso potenziali

Prendere in considerazione i processi di Azure Pipelines e CI/CD per:

  • Accelerazione dei cicli di vita di sviluppo e distribuzione delle applicazioni.
  • Creazione di qualità e coerenza in un processo di compilazione e rilascio automatizzato.
  • Aumento della stabilità e del tempo di attività dell'applicazione.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Eccellenza operativa

  • Considera l'implementazione di infrastruttura come codice (IaC) per definire l'infrastruttura e distribuirla nelle pipeline.

  • Prendere in considerazione l'uso di una delle attività di tokenizzazione disponibili nel marketplace VSTS. In questo contesto, spesso si fa riferimento a un processo in cui le informazioni riservate (ad esempio, chiavi API, password o altri segreti) vengono sostituite con token o segnaposto durante la distribuzione o la configurazione.

  • Usa le variabili di rilascio nelle definizioni di release per guidare i cambiamenti di configurazione degli ambienti. Le variabili di rilascio possono essere incluse in un'intera versione o in un determinato ambiente. Quando si usano le variabili per le informazioni segrete, assicurarsi di selezionare l'icona del lucchetto.

  • È consigliabile usare agenti autogestiti se si distribuisce su risorse che operano in una rete virtuale protetta. È anche possibile prendere in considerazione gli agenti self-hosted se si esegue un volume elevato di compilazioni. Nei casi di volumi di compilazione elevati, gli agenti self-hosted possono essere utilizzati per velocizzare le compilazioni in modo economico.

  • È consigliabile usare Application Insights e altri strumenti di monitoraggio il prima possibile nella pipeline di versione. Molte organizzazioni iniziano a monitorare solo nell'ambiente di produzione. Monitorando gli altri ambienti, è possibile identificare i bug in precedenza nel processo di sviluppo ed evitare problemi nell'ambiente di produzione.

  • Prendere in considerazione l'uso di risorse di monitoraggio separate per la produzione.

  • È consigliabile usare pipeline YAML anziché l'interfaccia classica. Le pipeline YAML possono essere considerate come altro codice. Le pipeline YAML possono essere archiviate nel controllo del codice sorgente e nella versione, ad esempio.

  • È consigliabile usare modelli YAML per promuovere il riutilizzo e semplificare le pipeline. Ad esempio, nella pipeline PR e CI sono simili. È possibile usare un singolo modello con parametri per entrambe le pipeline.

  • Prendere in considerazione la creazione di ambienti oltre la gestione temporanea e la produzione per supportare attività quali test di accettazione manuale dell'utente, test di prestazioni e test di carico e rollback.

Ottimizzazione dei costi

L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

I costi di Azure DevOps dipendono dal numero di utenti dell'organizzazione che richiedono l'accesso, oltre ad altri fattori, ad esempio il numero di build/versioni simultanee necessarie e il numero di utenti di test. Per altre informazioni, vedere prezzi di Azure DevOps.

Questo calcolatore prezzi fornisce una stima per l'esecuzione di Azure DevOps con 20 utenti.

Azure DevOps viene fatturato per ogni utente al mese. Potrebbero essere previsti altri addebiti a seconda delle pipeline simultanee necessarie, oltre ad altri utenti di test o licenze di base utente.

Sicurezza

  • Quando si sceglie tra l'uso di agenti ospitati da Microsoft o auto-ospitati , prendere in considerazione i vantaggi di sicurezza degli agenti ospitati da Microsoft.

  • Assicurarsi che tutte le modifiche apportate agli ambienti vengano eseguite tramite le pipeline. Implementare controlli degli accessi in base al ruolo (RBAC) sul principio dei privilegi minimi, impedendo agli utenti di accedere agli ambienti.

  • Valutare la possibilità di integrare i passaggi in Azure Pipelines per tenere traccia delle dipendenze, gestire le licenze, analizzare le vulnerabilità e mantenere aggiornate le dipendenze.

Passaggi successivi

Esaminare le risorse seguenti per altre informazioni su CI/CD e Azure DevOps: