Introduzione
Questo modulo illustra i modelli di distribuzione e spiega l'architettura dei microservizi per migliorare il ciclo di distribuzione ed esaminare i modelli di distribuzione classici e moderni.
Il recapito continuo è un'estensione dell'integrazione continua. Si tratta di rendere le modifiche disponibili per i clienti in modo rapido e usando metodi sostenibili.
Il recapito continuo va oltre e le modifiche che passano attraverso le pipeline di produzione vengono rilasciate ai clienti.
Il recapito continuo non si limita alla gestione del rilascio.
Il recapito continuo riguarda il processo, le persone e gli strumenti necessari per garantire il recapito del software su richiesta.
La distribuzione è un solo passaggio del processo di recapito continuo. Per eseguire la distribuzione su richiesta o più volte al giorno, è necessario che siano presenti tutti i prerequisiti.
Ad esempio:
Strategia di test
La strategia di test deve essere pronta. Se è necessario eseguire molti test manuali per convalidare il software, questo rappresenta un collo di bottiglia al recapito su richiesta.
Procedure di codifica
Se il software non è scritto in modo sicuro e gestibile, è probabile che non si riesca a mantenere una cadenza di rilascio elevata.
Quando il software è complesso a causa di un debito tecnico elevato, è difficile modificare il codice in modo rapido e affidabile.
La scrittura di software di alta qualità e di test di alta qualità è una parte essenziale del recapito continuo.
Architettura
L'architettura dell'applicazione è sempre importante. Ma, quando si implementa il recapito continuo, lo è forse ancora di più.
Se il software è un monolite con un livello di accoppiamento molto stretto tra i vari componenti, è difficile recapitare il software in modo continuo.
Ogni parte modificata potrebbe influire su altre parti che non sono state modificate. I test automatizzati possono tenere traccia di molte di queste dipendenze inaspettate, ma è comunque difficile.
Quando si lavora con team diversi, va considerato anche l'aspetto temporale. Quando il team A si affida al servizio del team B, il team A non può eseguire il recapito finché il team B non ha finito. Questo introduce un altro vincolo sul recapito.
Il recapito continuo per prodotti software di grandi dimensioni è complesso.
Per le parti più piccole, è più facile. Quindi, in molti casi, la suddivisione del software in parti più piccole e indipendenti è una buona soluzione.
Un approccio alla risoluzione di questi problemi consiste nell'implementare i microservizi.
L'integrazione continua è uno dei pilastri principali di DevOps.
Dopo aver creato il codice in un sistema di controllo della versione, è necessario un modo automatizzato per integrarlo su base continuativa.
È possibile usare Azure Pipelines per creare un servizio CI/CD multipiattaforma completo di tutte le funzionalità.
È compatibile con il provider Git preferito dall'utente e consente di eseguire la distribuzione nella maggior parte di servizi cloud più importanti, incluso Azure.
Questo modulo illustra in dettaglio le procedure di integrazione continua e i pilastri per implementarle nel ciclo di vita dello sviluppo, i relativi vantaggi e le proprietà.
Obiettivi di apprendimento
Dopo aver completato questo modulo, gli studenti e i professionisti saranno in grado di:
- Descrivere i modelli di distribuzione.
- Spiegare un'architettura di microservizi.
- Comprendere i modelli di distribuzione classici e moderni.
- Pianificare e progettare l'architettura.
Prerequisiti
- Conoscenza di DevOps e dei relativi concetti.
- Familiarità con i principi di controllo della versione (prerequisito utile, ma non necessario).
- Esperienza in un'organizzazione che fornisce software.