Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo presenta un'architettura di base per la creazione di una pipeline di integrazione continua e distribuzione continua (CI/CD) con Azure Pipelines. Usare questa architettura come punto di partenza se è necessario automatizzare la compilazione, il test e la distribuzione di applicazioni in ambienti di staging e produzione in Azure. L'architettura definisce tre pipeline, richieste pull, integrazione continua (CI) e distribuzione continua (CD) e illustra come interagiscono con Azure Repos, Azure Key Vault e Monitoraggio di Azure per convalidare, compilare e distribuire le app in modo sicuro.
Architettura
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:
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.
pipeline CI - Un merge in Azure Repos Git attiva una pipeline CI. Questa pipeline esegue gli stessi controlli della pipeline PR, oltre ai test di integrazione. La pipeline CI esegue i test di integrazione anziché la pipeline PR per due motivi:
- I test di integrazione possono essere a elevato utilizzo di risorse, quindi l'esecuzione dopo un merge bilancia la velocità di sviluppo con il rilevamento dei bug.
- Il superamento dei test in una pull request non garantisce che continuino a essere superati dopo il merge, perché le modifiche al branch principale possono introdurre nuovi problemi che solo i test eseguiti dopo il merge riescono a rilevare.
Questi test di integrazione non devono richiedere la distribuzione della soluzione, perché gli artefatti di compilazione non sono ancora stati creati. Se un test richiede segreti, la pipeline li recupera da Azure Key Vault. Se un controllo ha esito negativo, la pipeline termina e lo sviluppatore deve apportare le modifiche necessarie. Una corretta esecuzione di questa pipeline crea e pubblica gli artefatti di compilazione.
il trigger della pipeline CD: la pubblicazione di elementi attiva la pipeline CD.
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.
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.
Monitoraggio - Monitoraggio di Azure 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. Log Analytics di Azure 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.
Azure Artifacts feed consentono di gestire e condividere pacchetti software, ad esempio Maven, npm e NuGet. I feed consentono di gestire il ciclo di vita dei pacchetti, inclusi il controllo delle versioni, la promozione e il ritiro dei pacchetti, che consentono al team di usare le versioni più recenti e sicure delle dipendenze.
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. App Service supporta slot di distribuzione come staging e produzione, quindi è 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 che non sono possibili con il servizio app.
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.
Servizio Azure Kubernetes (AKS) è un cluster Kubernetes gestito in Azure. Kubernetes è una piattaforma di orchestrazione dei contenitori open source.
App contenitore di Azure 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 : le procedure CI/CD appropriate riducono drasticamente il rischio di rilasciare nuove funzionalità, perché 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, che è un 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.
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 self-hosted se si esegue la distribuzione in risorse in esecuzione in una rete virtuale protetta o se si esegue un volume elevato di compilazioni. Gli agenti ospitati autonomamente possono aiutarti ad accelerare le compilazioni in modo economicamente vantaggioso su larga scala.
È 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.
Prendere in considerazione l'integrazione dei passaggi in Azure Pipelines per tenere traccia delle dipendenze, gestire le licenze, analizzare le vulnerabilità e mantenere aggiornate le dipendenze.
Passaggi successivi
Crea la tua prima pipelineCompila, testa e distribuisci progetti .NET CoreCompila e distribuisci un'app Web Node.js