Che cos'è il recapito continuo?
In questa unità il team di Tailspin si confronterà sul modo in cui sfruttare una pipeline di recapito continuo (CD) per agevolare il prossimo rilascio.
Il team di Tailspin è ottimista riguardo il processo di compilazione. Dispongono di un processo automatizzato in esecuzione in Azure Pipelines, il che significa che l'ambiente di compilazione è stabile. Amita sa immediatamente quando deve testare un artefatto e trova un numero minore di bug da quando Andy e Mara hanno iniziato ad aggiungere unit test e test di qualità al codice. Tutto sembra procedere per il meglio. Queste sono le impressioni del team.
Riunione del mattino
Il team si trova nella sala riunioni in attesa di Irwin, il product manager, che li ha convocati. Si aspettano di fornirgli informazioni sullo stato di avanzamento. Ma quando Irwin entra, non sembra felice e inizia subito a parlare.
Irwin: Questa mattina ho avuto una riunione con il team di gestione. Si chiedono il motivo per cui il rilascio dei giochi e dei siti Web è molto lungo. I nostri concorrenti più stretti presentano nuove funzionalità e nuovi giochi molto più velocemente di noi. È necessario velocizzare le operazioni. Non sto avvisando soltanto voi, ma tutti i team. Cosa possiamo fare per velocizzare la distribuzione?
Andy: La richiesta ci coglie all'improvviso, ma abbiamo anticipato i tempi. La compilazione dei siti Web è già automatizzata. Adesso probabilmente è giunto il momento di estendere l'automazione al processo di rilascio.
Irwin: Come si esegue questa operazione?
Mara: Abbiamo creato una pipeline di compilazione automatizzata usando Azure Pipelines. In questo modo si compila un artefatto che Amita può testare. È anche possibile creare una pipeline di recapito continuo o CD.
Irwin: Che cos'è una pipeline CD?
Mara inizia a spiegare, ma viene interrotta dal suono del cellulare di Irwin. Irwin legge un SMS e borbotta sottovoce.
Irwin: Scusatemi, è urgente, devo andare. Nel frattempo confrontatevi in merito al ripristino continuo e fatemi sapere a breve.
Andy guarda il team.
Andy: Caffè?
Andy e il resto del team si recano alla caffetteria per elaborare un piano.
Che cos'è il recapito continuo?
Il team sta incontrando il caffè per capire come configurare un flusso di lavoro di recapito continuo.
Andy: Mara, puoi dirci cosa sai del recapito continuo?
Mara: Secondo me, il recapito continuo e DevOps sono inseparabili. Abbiamo definito DevOps come l'unione di persone, processi e prodotti per fornire costantemente valore agli utenti finali.
Con CD si intende un insieme di processi, strumenti e tecniche per fornire un recapito continuo, rapido e affidabile del software. Sebbene la configurazione di una pipeline sia una parte fondamentale, il recapito continuo consente anche di impostare un ambiente di lavoro in cui:
- Avere un processo affidabile e ripetibile per il rilascio e la distribuzione di software.
- Automatizzare il più possibile.
- Non cerchiamo di evitare di fare qualcosa che è difficile o doloroso; Al contrario, lo facciamo più spesso in modo da capire come renderlo routine.
- Mantenere tutti gli elementi nel controllo del codice sorgente.
- Siamo tutti d'accordo che l'espressione fatto significa rilasciato.
- La qualità viene integrata nel processo e non è mai un elemento secondario.
- Tutti sono responsabili del processo di rilascio. Non si lavora più in silos.
- Si cerca sempre di migliorare.
Abbiamo già messo in atto molte di queste idee e constatato un miglioramento nel modo di lavorare. Il recapito continuo è un'estensione di un processo già avviato.
Perché è necessario il recapito continuo?
Il recapito continuo consente ai team del software di fornire aggiornamenti affidabili ai clienti a cadenza ravvicinata. Consente inoltre di garantire che clienti e stakeholder dispongano rapidamente delle funzionalità e delle correzioni più recenti.
Di seguito viene riportata la discussione tra i membri del team.
Andy: Grazie, Mara. Il recapito continuo è necessario perché il mondo è cambiato. Le nuove funzionalità vengono rilasciate più velocemente. Gli aggiornamenti e le correzioni di bug devono essere immediatamente disponibili. La velocizzazione dei rilasci richiesta del team di gestione è semplicemente una risposta alle esigenze dei clienti. Se non siamo in grado di soddisfare le richieste, i clienti si rivolgeranno altrove.
Tim: Va bene! Non vedo l'ora di iniziare.
Andy: Grazie a tutti. Io e Mara creeremo un semplice modello di verifica (PoC). Osservando una pipeline CD in azione sarà molto più semplice comprenderne il funzionamento.
Amita: Buona fortuna.
Il team lascia Andy e Mara a elaborare i dettagli.
Qual è la differenza tra recapito continuo e pubblicazione diretta?
Molti strumenti di sviluppo consentono di pubblicare l'applicazione direttamente in un ambiente di destinazione, ad esempio Microsoft Internet Information Services (IIS) o Azure. Ad esempio, è possibile pubblicare un'app ASP.NET Core in Azure usando Visual Studio. Questo processo viene talvolta denominato pubblicazione diretta.
Si tratta di un ottimo modo per creare rapidamente un prototipo. Ad esempio, è possibile pubblicare direttamente l'applicazione in Azure in modo da condividere una nuova idea con il team. Questa tecnica presenta tuttavia alcune limitazioni.
Il recapito continuo consente a tutti i membri del team di testare, distribuire e monitorare l'applicazione in modo continuo ogni volta che si archivia il codice. Quando si pubblica direttamente l'applicazione, non c'è alcuna garanzia che il codice sia stato testato correttamente o si comporterà come previsto in caso di utilizzo concreto.
In questo breve video, Abel Wang, cloud Advocate presso Microsoft, spiega come.
Qual è la differenza tra recapito continuo e distribuzione continua?
Nella community di DevOps si usano le espressioni recapito continuo e distribuzione continua. Questi termini si riferiscono alla stessa cosa? In questo breve video, Abel spiega la differenza.
Quali strumenti di recapito continuo è possibile usare?
Al termine della riunione, Andy e Mara pianificano i passaggi successivi. Al momento usano Azure Pipelines per la compilazione del software e vogliono prendere in considerazione gli strumenti disponibili, tra cui Azure Pipelines, per agevolare il processo di rilascio.
Mara: Con che cosa cominciamo?
Andy: Prima di tutto, è necessario concordare lo strumento di gestione del rilascio. Lo strumento scelto deve:
- Supportare il sistema di controllo della versione.
- Consentire la distribuzione in più ambienti per poter testare e convalidare il lavoro.
- Semplificare la definizione delle attività di distribuzione.
- Consentire una facile estensione.
Mara: Azure DevOps si integra con molte altre soluzioni di integrazione continua e recapito continuo. Molte soluzioni sono già disponibili, ma non abbiamo investito in nessuna di queste. Se lo avessimo fatto, avremmo potuto usare quelle. I sistemi CI e CD più diffusi includono Jenkins, Circle CI, GitLab, Travis CI e Azure Pipelines.
Questi strumenti hanno delle analogie, ma ognuno presenta anche punti di forza specifici. Tra questi ci sono strumenti open source, gratuiti e a pagamento. Forniscono inoltre integrazioni predefinite con altri strumenti software.
Ad esempio, Jenkins è uno strumento open source usato da molte aziende e dispone di diversi plug-in. L'esecuzione di Circle CI può avvenire nel cloud o in locale. Sarebbe necessario personalizzarlo. GitLab rappresenta una singola applicazione per l'intero ciclo di vita di sviluppo del software. Si tratta quindi di una soluzione più grande del necessario. Possiamo continuare a usare Azure Pipelines.
In questo breve video Abel illustra come usare le procedure consigliate di DevOps per distribuire il codice in Azure.
Mara: Secondo me dovremmo continuare a usare Azure Pipelines.
Andy: Sono d'accordo. Finora abbiamo lavorato molto bene con Azure Pipelines, inoltre non sarà necessario apprendere una tecnologia nuova.
Mara: Bene. Procediamo con i dettagli della pipeline.
Andy e Mara si spostano in sala riunioni per pianificare la pipeline CD.