This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Italiano

Implementazione minima della Continuous Delivery

Implementazione minima della Continuous Delivery

“La Continuous Delivery migliora sia la velocità di rilascio che la qualità del software ed aiuta a migliorare la cultura, riduce i burnout e gli sforzi tipici legati al rilascio del software in produzione”.

– Accelerate (Unofficial translation)

Noi, i firmatari, riteniamo che la definizione di un’implementazione minima della Continuous Delivery (CD) sia necessaria per migliorare il flusso di rilascio del software. Sebbene i contesti in cui lavoriamo possano essere diversi, esistono pratiche universali. Definendo tali pratiche possiamo:

  • Introdurre alla Continuous Delivery nuovi praticanti in modo coerente
  • Discutere le pratiche ingegneristiche che costituiscono CD
  • Aiutarci a vicenda a migliorare le nostre conoscenze e capacità attuali

Soltanto partendo da questo set minimo di pratiche essenziali potremmo iniziare a vedere i vantaggi della Continuous Delivery.

Le pratiche sotto elencate costituiscono un’implementazione minima, un punto di partenza. Il risultato atteso è il miglioramento continuo della velocità, della qualità e della sicurezza della pipeline di rilascio.

Continuous Delivery

La CD è la disciplina ingegneristica che consente di rilasciare nuove funzionalità e modifiche software in modo standard e sicuro. La CD copre un ampio spettro di attività a seconda di cosa deve essere rilasciato. Tuttavia, ci sono comportamenti ed abilità che devono essere rispettati in qualsivoglia contesto, perché si possa parlare di “Continuous Delivery”.

Il set minimo di attività richieste per la CD sono:

  • Continuous integration (Integrazione Continua)
  • La application pipeline è l’unico percorso per il rilascio in produzione
  • La pipeline decide la rilasciabilità delle modifiche software, e il suo verdetto è definitivo
  • Gli artefatti creati dalla pipeline soddisfano sempre la definizione di rilasciabilità definition of deployable della specifica organizzazione
  • Artefatti immutabili (Immutable artifact): nessuna modifica manuale dopo i commit
  • Tutto il lavoro si ferma se la pipeline fallisce
  • Utilizzare ambienti di test il più possibile simili all’ambiente di produzione
  • Rollback su richiesta
  • La configurazione dell’applicazione viene distribuita assieme agli artefatti

Continuous Integration (Integrazione continua)

La CI è l’attività che ci consente di integrare continuamente il lavoro di ciascun membro del team nel trunk del repository e verificare che questo sia sempre, al meglio delle nostre conoscenze, funzionante e rilasciabile.

Le attività minime richieste dalla CI sono:

  • Trunk-based development
  • Il lavoro viene integrato nel trunk almeno una volta al giorno
  • Una suite di test automatici verifica il lavoro prima che venga integrato nel trunk
  • Una suite di test automatici verifica il lavoro dopo essere stato integrato nel trunk
  • Tutto il lavoro si ferma se la pipeline fallisce
  • Il nuovo lavoro non deve causare malfunzionamenti alle funzionalità già rilasciate

Trunk-based Development

Il Trunk-based Development è il modello di branching necessario a soddisfare la definizione della CI. La CI evita la perdita delle modifiche, il rischio di corruzione che deriva dall’integrazione e dalla risoluzione dei conflitti, e riduce lo spreco dovuto ad attività che potrebbero aumentare la dimensione degli insiemi di modifiche.

  • Le attività minime richieste dal TBD sono:
    • Tutte le modifiche devono essere integrate nel trunk
    • Se si utilizzano i branch:
      • Devono nascere dal trunk
      • Devono essere reintegrati nel trunk
      • Devono essere di breve durata e rimossi dopo l’integrazione

Oltre il minimo

La CD minima non è il primo passo in un modello di maturità, tuttavia è il minimo indispensabile su cui dovrebbero essere costruite molte altre pratiche, come richiesto dal proprio contesto. Per facilitare il vostro percorso oltre la CD minima, manteniamo di seguito una lista di risorse relative alla Continuous Delivery che abbiamo trovato molto utili nel nostro percorso.

Queste risorse contengono sia conoscenze di base, sia conoscenze necessarie a farvi diventare un’organizzazione CD “d’élite”. Sono risposte specifiche alla domanda “Cosa ci impedisce di andare in produzione oggi?”

Vedi la lista.

Perche abbiamo costruito questa lista?

Per maggiori dettagli sulla CD minima e risposte su altre domande comuni, vi rimandiamo alle FAQs.

Per contribuire o diventare firmatari

Vedere linee guida per contribuire.

Firmatari

I firmatari hanno firmato la versione originale in inglese e la lista corrente dei nomi è pubblicata solo in quella versione

Traduzione

Questa traduzione è uno sforzo della comunità per facilitare la diffusione dei concetti legati alla CD oltre la barriera linguistica. I firmatari non possono confermare la correttezza della traduzione.

Tradotto dalla versione: 4de610d, 2021-10-19

1 - Domande Frequenti (FAQ)

Implementazione minima della Continuous Delivery

Motivazioni

Nell’ottobre 2021, durante il summit DevOps Enterprise, molti di noi si sono incontrati per discutere il problema del costante fraintendimento della Continuous Delivery. Abbiamo quindi deciso di condurre un esperimento per migliorarne la comprensione.

Nel libro “Accelerate” del 2017, gli autori osservavano che:

“La Continuous Delivery migliora sia la velocità di rilascio che la qualità del software ed aiuta a migliorare la cultura, riduce i burnout e gli sforzi tipici legati al rilascio del software in produzione”.

Tale osservazione è basata sulla loro esperienza e sui dati raccolti negli anni tramite i questionari “State of DevOps” (“Stato della DevOps”). Noi stessi abbiamo constatato gli stessi risultati, ma soltanto utilizzando in modo appropriato un set di pratiche fondamentali. Quando queste pratiche non vengono utilizzate, vengono fraintese o un’organizzazione tenta di prendere scorciatoie, i risultati non arrivano e allora si tende a dire che la CD è una moda passeggera o che non è adatta al proprio, speciale, contesto. Nessuna delle due affermazioni corrisponde a verità.

Stabilendo una linea di partenza, speriamo di fornire una chiara tabella di marcia di azioni fondamentali che devono essere messe in pratica. Se ci chiedessimo “perché non possiamo farlo anche noi?” e quindi procedessimo a risolvere quei problemi, riusciremmo ad ottenere gli stessi benefici di cui dicono di godere le altre organizzazioni.

Perché firmare?

Se pratichi la CD e sei d’accordo con con questi obiettivi, sentiti libero di inviare una Pull Request per aggiungere la tua firma.

Cosa fare se cambio idea?

Non vogliamo tenere nessuno in ostaggio. Il nostro obiettivo è elevare il confronto attraverso un linguaggio comune. Basta quindi aprire una issue o inviare una nuova PR. La firma sarà rimossa prontamente.

Come viene aggiornata la lista delle pratiche?

I manutentori della lista operano attraverso il consenso. Per essere inserita nella lista, ciascuna pratica deve essere essenziale a prescindere dal contesto. Se una pratica non è nella lista significa che, o non soddisfa lo standard minimo assoluto in ogni contesto, o è in conflitto con una delle pratiche elencate. Il miglior modo per suggerire una modifica o un’aggiunta alla lista è creare una “issue” su GitHub.

È solo questo ciò di cui abbiamo bisogno per implementare la CD?

Oh, no, questo è il minimo indispensabile.

Come possiamo utilizzare questi contenuti per migliorare?

La CD richiede la CI (Continuous Integration) e la CI richiede il Trunk-based Development. Comincia dal fondo e procedi verso l’alto. Chiediti: “perché non riusciamo ancora a realizzare questa o quell’altra cosa?”. Risolvere quel problema è il motore del miglioramento dell’organizzazione. Non abbiamo ancora constatato un singolo caso in cui la CD non potesse essere applicata. In alcuni contesti, potrebbe solo volerci più tempo per risolvere certi problemi. Ne vale comunque la pena. La CD migliora tutto.

Perché la pipeline dovrebbe dettare legge per il rilascio?

“Se la pipeline riporta che tutto è funzionante, ciò è quanto basta - ci spinge a concentrarci su cosa significa “rilasciabile.” - Dave Farley

Cos’è la configurazione dell’applicazione (Application Configuration)?

Il termine “Configurazione” è abusato e non ha una definizione standard in tutto il nostro settore. Noi sposiamo la definizione The Twelve-Factor Appconfig in cui “configurazione” dipende dell’ambiente di installazione (varia in base al rilascio) e “configurazione dell’applicazione” è interna all’applicazione e NON varia in base all’ambiente di installazione.

Cosa significa artefatti immutabili?

Fondamentale per CD è che che gli artefatti distribuiti tramite la pipeline vengano validati. Lo stesso artefatto viene creato una volta e distribuito in tutti gli ambienti. Una cattiva pratica comune è costruire un artefatto per ogni ambiente. Questo è il motivo per cui il trunk-based development è così importante.

Che cosa intendiamo per “rilasciabile” (deployable)?

Ogni organizzazione dovrebbe adottare criteri non negoziabili per i rilasci software. Questi potrebbero includere i controlli di sicurezza, conformità, stabilità, reattività, ecc. La pipeline dovrebbe avere l’ultima parola per tutto ciò. Raccomandiamo il video di Dave Farley Esempio reale di una pipeline di rilascio nel settore Fintech