Manifesto

L’integrazione continua (Continuous Integration) è un processo e un flusso di lavoro per sviluppatori e impacchettatori. La consegna continua (Continuous Delivery) è un processo e un flusso di lavoro per il rilascio.

L’integrazione continua (Continuous Integration) mira a garantire che le modifiche difettose non impattino su altri sviluppatori, impacchettatori, manutentori o utenti. La consegna continua (Continuous Delivery) mira a garantire che le modifiche difettose non vengano consegnate o rilasciate.

L’integrazione continua ci permette di correggere rapidamente la rotta mentre sviluppiamo software verso un obiettivo in continua evoluzione. Il feedback fornito dall’integrazione continua è fondamentale per una distribuzione agile e ritmata del software. I test tardivi, eseguiti molto tempo dopo l’introduzione di una modifica, non sono scalabili rispetto al ritmo di Fedora.

Poiché ci sono diversi sforzi in corso sul fronte dell’Integrazione Continua, dobbiamo stabilire le regole di base per assicurarci che tutti stiamo giocando alla stessa partita. Quando chiamiamo un gioco "calcio", dobbiamo essere d’accordo su cosa significhi. Possiamo avere framework, implementazioni o test diversi, ma dobbiamo giocare alla stessa partita.

La Definizione

Non potete chiamarla "Integrazione Continua" a meno che voi non…​

  1. Assemblatelo insieme come in produzione, poi provatelo come farebbe un utente. Questa è Integrazione.

  2. Eseguiate questi test di integrazione per ogni singola "modifica". Questa è la Continuità.

Senza questi requisiti, potrebbe trattarsi di "test unitari", "test di accettazione", "test di regressione", "controllo qualità" o di altre fasi della pipeline…​ ma non è "integrazione continua". Potreste persino eseguire nuovamente gli stessi test in un secondo momento, all’interno di uno di questi altri processi di testing.

Costruire un componente, comporlo con altri e assemblarlo in un sistema simile a quello di produzione fa tutto parte dell’integrazione. Con "flusso di modifiche" (change stream) ci si riferisce alle modifiche su cui l’integrazione agisce continuamente. Uno sviluppatore è colui che ha avviato e/o implementato la modifica ed è il destinatario del feedback dei test. In Fedora, questa figura corrisponde a un impacchettatore (packager) o a un manutentore (maintainer). Di solito applichiamo questa integrazione a un flusso di modifiche software, ma in altri casi può trattarsi di modifiche hardware o di altro tipo.

La consegna continua (Continuous Delivery) consiste nel prendere alcune di queste integrazioni andate a buon fine e consegnarle.

Manifesto

  1. Un test ha valore zero finché il suo risultato non influenza il comportamento di un osservatore.

  2. Il miglior osservatore per il risultato di un test è lo sviluppatore o l’impacchettatore che ha avviato e/o introdotto la modifica oggetto dell’integrazione.

  3. Il beneficio dell’integrazione continua è inversamente proporzionale alla dimensione della modifica. Molte piccole modifiche iterative superano di gran lunga una singola massiccia modifica cumulativa.

  4. Un feedback rapido per lo sviluppatore o l’impacchettatore che ha effettuato la modifica catturerà la loro attenzione. L’obiettivo deve essere quello di fornire i risultati dei test in poche ore, non in giorni.

  5. Gli impacchettatori si assumono la responsabilità solo dei test ai quali possono contribuire direttamente.

  6. Gli impacchettatori rispettano i test e i sistemi di testing che producono risultati affidabili. Al contrario, ignorano ed evitano i test e i sistemi che si dimostrano instabili (flakey).

  7. Gli impacchettatori non dovrebbero essere costretti a cercare i risultati dei test al di fuori del proprio flusso di lavoro.

  8. Gli impacchettatori dovrebbero essere in grado di eseguire i singoli test sulle proprie macchine.

  9. Il test ideale può essere aggiornato di pari passo con le modifiche che sta verificando. L’obiettivo deve essere quello di memorizzare un test insieme al software a cui il test è maggiormente correlato.

  10. Il posto migliore per testare una modifica è prima che quest’ultima abbia un impatto su chiunque altro.

  11. Una piccola suite di test che segue questi principi ha un valore di gran lunga superiore per l’integrazione continua rispetto a una suite imponente che non lo fa.

Le Regole

L’integrazione continua diventa autosufficiente seguendo due regole fondamentali…​

Per poter scalare il nostro impegno nella CI, quest’ultima deve essere resa autosufficiente. Non è così difficile. Queste regole di base sono i requisiti per costruire un ciclo autosufficiente in cui i test crescono invece di marcire.

1. I test devono poter essere modificati dalle stesse persone che effettuano la modifica al software

Sviluppatori e impacchettatori devono essere in grado di contribuire con modifiche ai test e di eseguirli. I test diventano responsabilità degli impacchettatori e del ciclo di packaging. È possibile iniziare con un piccolo corpus di test che soddisfi questo requisito. Questo piccolo corpus finirà per superare qualunque test "non Open Source".

Motivazione: Test open source e riproducibili consentono a sviluppatori e impacchettatori di contribuire, correggere i test obsoleti e far crescere le suite di test. In questo modo, essi presteranno attenzione ai test e si occuperanno della loro manutenzione.

2. Feedback rapido alla persona che effettua una modifica

Lo sviluppatore o l’impacchettatore che apporta una modifica a un pacchetto o a un container ha bisogno di un feedback rapido da parte dell’integrazione continua. La modifica non dovrebbe procedere finché tale persona non interviene sui risultati di un fallimento dell’integrazione.

Motivazione: Un feedback rapido fa sì che gli sviluppatori e gli impacchettatori

  1. prestino attenzione ai test

  2. correggano i problemi mentre la modifica è ancora fresca nella loro mente e

  3. vincolino l’approvazione della modifica al superamento dei test.

Want to help? Learn how to contribute to Fedora Docs ›