Only Build Your Binaries Once

 06 Jan 2023 -  Giulio Vian

Uno dei principi evidenziati da Continuous Delivery   , già molti anni fa, è Only Build Your Binaries Once (Cap.5 p.113), traducibile con costruisci i tuoi binari una sola volta. Come accade a tutti i bravi principi, la sua formulazione è semplice ma le ramificazioni numerose. Quest’oggi cercherò di sviluppare le principali conseguenze e chiarire i motivi che giustificano il principio di generare i binari una volta sola. Prima di addentrarci bisogna chiarire che il termine “binari”, nel contesto degli autori originali ma anche in questo articolo, comprende ogni genere di artefatti prodotti dalla continuous integration (ossia la build) ed in particolare i pacchetti di installazione o distribuzione.

Leggi di più… ( ~7 Min.)

La pipeline CI/CD nel 2023

 24 Dec 2022 -  Giulio Vian

Ecco un lungo articolo in tempo per le vacanze natalizie. Oggi voglio darvi una panoramica su cosa prevedere in una moderna pipeline di Continuous Integration / Continuous Delivery (CI/CD). Com'è mio solito non mi focalizzerò su specifiche tecnologie quanto sul processo, limitando ad accenni di prodotti e soluzioni tecniche, quel tanto da esemplificare i concetti. A mio modesto parere, il migliore approccio per disegnare un processo, od anche un’architettura, è di procedere a ritroso, dall’obiettivo finale con i suoi requisiti fondamentali, all’indietro fino alla pianificazione dell’evoluzione del prodotto.

Leggi di più… ( ~17 Min.)

Rilasci non-funzionali

 10 Dec 2022 -  Giulio Vian

Cosa sono i rilasci non-funzionali? È presto detto: sono rilasci “tecnici” senza alcun cambiamento funzionale. Qualcuno si chiederà che senso abbia un rilascio senza modifiche al codice. Facile, non cambia il codice ma qualcosa al contorno che non è rilasciabile separatamente. Il caso più comune oramai è dover aggiornare una libreria vulnerabile con una versione più sicura, reimpacchettare e rilasciare di nuovo. Purtroppo negli ultimi anni il ritmo di questi cambiamenti è mutato drasticamente ed impatta noi e le nostre applicazioni!

Leggi di più… ( ~10 Min.)

Pacchettini o Containers?

 10 Oct 2022 -  Giulio Vian

In un precedente articolo ho considerato il principio che DevOps raccoglie da Lean, ossia l’importanza di minimizzare la dimensione dei rilasci. In Lean si parla di small batches, trattandosi di software riduciamo per quanto possibile la quantità di modifiche presenti in un rilascio. Con dei semplici esempli spero di aver dimostrato i vantaggi che se ne ricavano e come l’automazione sia conseguenza di minimizzare il peso dei nostri rilasci.

Oggi torniamo sul tema perché Accelerate   ci insegna che le organizzazioni con le migliori performances hanno valori altissimi per Deployment Frequency, la frequenza dei rilasci, fino a diversi rilasci giornalieri (p. 19).

 

Per quanto ciò sia innegabile per una organizzazione nel suo complesso, la metrica di Deployment Frequency deve esser considerata in modo diverso quando scendiamo a livello di una singola applicazione. La frequenza di aggiornamento dipenderà sia dalla maturità dell’applicazione che dalla sua importanza strategica. Tali fattori si compongono e mediano quando abbiamo un portafoglio IT con molte applicazioni sviluppate internamente.

Maturità

Ogni applicazione, sotto-sistema IT, system asset, o come lo si voglia chiamare ha uno specifico ciclo di vita, variamente suddiviso in quattro, cinque o più fasi (es: Acquisto, Rilascio, Uso, Manutenzione, Ritiro e Smaltimento).

Consideriamo ora solamente i sistemi sviluppati internamente, le applicazioni. Per questi gli stadi sono tipicamente quattro:

1. Sviluppo
2. Crescita
3. Maturità
4. Declino

Iniziamo con la prospettiva finanziaria per una singola applicazione o prodotto o servizio. Questa si focalizza sull’utilizzo ovvero sui ricavi. La curva di utilizzo che ci attendiamo è quella tipica di un prodotto, con una fase di crescita intensa dopo la pubblicità iniziale, una stabilizzazione e infine un declino fino al ritiro finale.

Veniamo ora alla prospettiva dello sviluppo ingegneristico. Qui ci interessa la frequenza con cui introduciamo modifiche nelle suddette applicazioni.

Uno schema tipico vede una fase di investimento pressoché costante fino a quando il prodotto o servizio non prende piede ed è possibile aumentare gli investimenti, dando maggior valore ai clienti. Una volta maturato il prodotto, l’investimento e dunque il tasso di cambiamento cala con una certa rapidità: è la fase in cui gli investitori cominciano ad incassare. Le novità diminuiscono e la manutenzione ordinaria diventa l’attività prevalente. Quando si comprende che il mercato non darà più ritorni per quel prodotto o servizio, ecco che restano solo attività di manutenzione per un parco utenti sempre più calante, fino al ritiro definitivo del prodotto.

Questo è un ragionamento semplificato naturalmente. Se l’applicazione vede una crescita esponenziale, succede non di rado che il disegno iniziale non sia in grado di sopportare il tasso di cambiamento né il carico crescente. Quando l’organizzazione, sulla base delle evidenze tecniche, decide per un ridisegno radicale, abbiamo la sostituzione di un prodotto con uno nuovo

La migrazione di Twitter da Ruby a Scala è tra gli esempi più noti di una riscrittura di un prodotto per adeguarlo alla crescita (vedi Twitter Shifting More Code to JVM, Citing Performance and Encapsulation As Primary Drivers (infoq.com)   e Twitter Engineering: Twitter Search is Now 3x Faster   ). Altri esempi sono Facebook Messenger ( Project LightSpeed: Rewriting Messenger to be faster, smaller, and simpler   ).

In sintesi: la quantità e frequenza dei cambiamenti per una applicazione varia nel tempo, declinando quando raggiunge la maturità.

Strategicità

La cosa più certa del futuro è la sua imprevedibilità. E dopo questa bella catalanata   (ai più giovani suggerisco guardare Le catalanate di “Quelli della notte” - Rai Teche   ) cerchiamo di descrivere quanto l’importanza strategica di una applicazione influisce sulla sua evoluzione.

Nella sezione Maturità il grafico dell’utilizzo appare ben definito, ma sarà aderente alla realtà solo quando l’applicazione ha concluso la propria esistenza! Durante le fasi iniziali si possono fare solo supposizioni su come evolverà la curva. In risposta alle condizioni del mercato, delle richieste degli utenti, delle scelte strategiche della dirigenza, quest’ultima può decidere di investire maggiormente o togliere risorse fino a decidere, ad esempio, di sostituire una soluzione fatta in casa con una commerciale (buy vs make). Chi fosse interessato ad approfondire il tema di calibrare l’investimento IT raccomando studiare lo strumento delle Wardley Maps   .

Abbiamo dunque due elementi che concorrono ad incrementare o diminuire il lavoro di sviluppo e di conseguenza la quantità di modifiche disponibili nel tempo per essere rilasciate in produzione.

Rilasci

Alcuni di voi saranno già saltati alle conclusioni di come i due elementi, maturità e strategicità, di un prodotto influenzano i rilasci, ma procediamo con ordine.

Chiaramente maggiore il numero di persone che concorrono ad un prodotto, una applicazione, maggiore la quantità di modifiche prodotte nell’unità di tempo.

È vero anche l’inverso: meno persone lavorano, minori cambiamenti vengono prodotti. Questo in particolare quando il prodotto si avvia al declino: le modifiche diventano infrequenti, una manciata all’anno, senza nuove funzionalità, solo correzioni e adeguamenti.

Questa semplice constatazione ha un impatto diretto sulla frequenza di rilascio: se non ci sono modifiche disponibili, cosa posso rilasciare?

Conclusione

In sintesi, la metrica Deployment Frequency ha senso solo a livello di una organizzazione con un portafoglio di applicazioni. Non può essere considerata a livello di una singola applicazione a meno di fattorizzare la maturità e l’investimento sulla stessa, il che vuol dire usare una metrica diversa.

In realtà, il vero approccio Lean richiede la capacità di rilasciare on-demand, ogni qualvolta sia necessario o utile. Da qui il bisogno di automazione anche per quei casi meno evidenti, come ho accennato in Automatizzare? Sempre! .

In futuro articolo, affronterò il tema dei rilasci non-funzionali di una applicazione e della sempre maggiore importanza che hanno nell’informatica moderna.

Voi che ne pensate?

Automatizzare? Sempre!

 30 Sep 2022 -  Giulio Vian

Alcuni anni fa ho tenuto una conferenza, dal titolo “Automate? Always!” (Automatizzare? Sempre!), per stimolare una discussione sull’automazione nell’ingegneria del software. Oggi metto per iscritto l’argomento di quella presentazione sperando di raggiungere un pubblico più vasto. Nota: in questo post mi riferisco a qualsiasi automazione nel ciclo di vita dello sviluppo software: spaziando dalle macro dell’editor agli script di distribuzione (con un’enfasi su questi ultimi). Per favore pazienta, perché questo post sarà un po’ più lungo degli altri, e considera che ci sarebbe da dire di più che un singolo articolo.

Leggi di più… ( ~7 Min.)

DevOps è solo automazione?

 09 Sep 2022 -  Giulio Vian

Un grosso equivoco su DevOps è che il suo scopo sia automatizzare. Nulla di più errato. L’automazione è un mezzo per un fine assai diverso. Il fine di DevOps è ottimizzare, massimizzare, il valore fornito agli utenti mediante la catena del lavoro IT. Per massimizzare il valore dobbiamo ridurre le dimensioni dei nostri rilasci. Rilasci con meno funzionalità ma più frequenti. Rilasci più frequenti sono meno efficienti se pensiamo di gestirli manualmente.

Leggi di più… ( ~3 Min.)

Cos'è l’architettura?

 02 Sep 2022 -  Giulio Vian

Le definizioni sono importanti e quando sento usare il termine architettura in riferimento a classi e pattern di programmazione interni ad un programma mi trovo in difficoltà. Probabilmente è un mio problema, così son andato a vedere cosa si dice in letteratura e non siamo in una situazione esaltante. Martin Fowler in Software Architecture Guide (martinfowler.com)   menziona due approcci: the shared understanding that the expert developers have of the system design

Leggi di più… ( ~3 Min.)

Blog aggiornato con Hugo e GitHub Actions

 25 Apr 2020 -  Giulio Vian

Tre anni fa scrivevo di come avevo migrato il contenuto del blog su Azure DevOps (da notare che aveva un nome diverso all’epoca). Oggi invece scrivo di come ho migrato il tutto su GitHub. Ritornando sulla soluzione ho scoperto quanto Hugo   sia evoluto e quante personalizzazioni posso buttare, grazie al principio fondante “le batterie sono comprese”. Oltre ad aver aggiornato la versione di Hugo da 0.24.1 a 0.

Leggi di più… ( ~2 Min.)