Il vasto repository centralizzato di Google serve come un’unica fonte di informazioni per decine di migliaia di sviluppatori sparsi in tutto il globo. La stragrande maggioranza del loro codice sorgente, precisamente il 95%, risiede qui, con l’eccezione di progetti specializzati come Google Chrome e Android che hanno i loro repository dedicati.
C’è un paper in inglese molto interessante che trovi in fondo all’articolo che descrive in dettaglio il percorso fatto da Google nella gestione del codice. Di seguito trovi un riassunto dei punti salienti.
La gestione del codice in Google
Il percorso di Google in termini di gestione del codice ha avuto inizio con l’uso del sistema di controllo versione CVS. In seguito, hanno optato per Perforce per poi, infine, sostituirlo con l’innovativo sistema di gestione del codice chiamato Piper. Secondo dati risalenti al 2016, Piper custodisce oltre 2 miliardi di righe di codice e gestisce circa 40.000 commit al giorno, contribuiti da un esercito di oltre 10.000 ingegneri.
La maggior parte degli ingegneri di Google adotta un modello di sviluppo noto come sviluppo basato sul tronco/ramo (trunk-based development). Questo modello permette di gestire progetti di grande scala con un notevole successo. Nel dettaglio, ogni modifica al codice viene implementata direttamente sul ramo principale e sottoposta a revisioni del codice. Questa metodologia elimina efficacemente i problemi di fusione del codice, evitando quello che viene spesso descritto come “merge hell”.
Uno strumento chiamato Tricorder è incaricato di eseguire i primi controlli automatici quando i programmatori cercano di inserire nuovo codice nel repository. Tricorder fornisce anche un feedback immediato allo sviluppatore, facilitando il processo di sviluppo. Successivamente, la revisione del codice può essere effettuata tramite Critique, uno strumento dedicato alle revisioni del codice.
Per operazioni di refactoring su larga scala, ottimizzazioni e pulizia del codice, gli ingegneri utilizzano Rosie. Questo potente strumento permette di suddividere le modifiche in piccoli lotti che possono essere esaminati e approvati da ciascun proprietario del codice prima di essere integrati nel progetto.
Il modello adottato da Google offre numerosi vantaggi:
Versionamento unificato: con un singolo repository, è possibile gestire facilmente tutte le versioni del software.
Condivisione estensiva del codice: gli sviluppatori possono riutilizzare moduli e librerie di codice in diversi progetti.
Gestione semplificata delle dipendenze: le dipendenze tra diverse parti del codice sono più facili da gestire in un unico repository.
Modifiche atomiche: le modifiche possono essere applicate a tutto il codice sorgente in modo consistente e simultaneo.
Refactoring su larga scala: é possibile fare modifiche significative all’intera base di codice in modo più efficace.
Collaborazione tra team: facilita la collaborazione e la condivisione di codice tra diversi team.
Flessibilità nella proprietà del codice: ogni sviluppatore o team può avere la proprietà di una parte specifica del codice.
Visibilità del codice: tutti gli sviluppatori hanno accesso a tutto il codice sorgente, migliorando la comprensione e la collaborazione.
Tuttavia, ci sono alcuni svantaggi come la necessità di creare e scalare strumenti personalizzati per lo sviluppo e l’esecuzione del software, mantenere la salute del codice e gestire la complessità potenziale del codice (come dipendenze non necessarie).
E voi? Avete mai considerato di adottare l’approccio monorepo nei vostri progetti?
Contenuti
Gli strumenti adottati da Google
CVS
CVS, che sta per Concurrent Versions System (Sistema di Versionamento Concorrente), è uno strumento di controllo della versione che consente agli sviluppatori di software di gestire e tracciare le modifiche apportate al codice sorgente nel corso del tempo. È stato uno dei primi sistemi di controllo della versione ad essere ampiamente adottato in ambito di sviluppo software.
Il principale vantaggio di CVS è che permette a più sviluppatori di lavorare simultaneamente su un unico progetto senza sovrascrivere il lavoro degli altri. Ogni sviluppatore può “controllare” una copia del progetto, apportare modifiche e poi “effettuare il commit” di queste modifiche nel repository centrale.
Un altro punto di forza di CVS è la possibilità di “tornare indietro” nel tempo per visualizzare le versioni precedenti del codice, funzione molto utile per individuare la genesi di eventuali bug.
Nonostante i suoi punti di forza, CVS ha alcune limitazioni rilevanti, come l’incapacità di rinominare file e directory e la mancanza di un supporto atomico per le transazioni (sotto ho aggiunto alcuni dettagli su questo argomento). Questi limiti hanno portato allo sviluppo e all’adozione di nuovi sistemi di controllo della versione, come Subversion e Git.
Risorse e link utili:
| Risorse | Link |
|---|---|
| Guida introduttiva a CVS | Link alla guida |
| Confronto tra CVS e Git | Link al confronto |
| Corso online su Git (come alternativa a CVS) | Link al corso |
Perforce
Perforce è un sistema di controllo delle versioni (Version Control System, VCS) altamente scalabile e sicuro, utilizzato principalmente da sviluppatori di software per gestire e tracciare le modifiche al codice sorgente nel corso del tempo.
Uno dei principali vantaggi di Perforce è la sua capacità di gestire grandi codebase e di supportare migliaia di utenti contemporaneamente. Questo lo rende particolarmente adatto per organizzazioni di grandi dimensioni con team di sviluppo di software molto ampi, come nel caso di Google prima dell’adozione di Piper.
Inoltre, Perforce offre un’ampia gamma di funzionalità avanzate tra cui gestione delle branch, gestione delle versioni binarie, refactoring del codice, rilevamento dei conflitti di merge e molto altro ancora.
Tuttavia, nonostante le sue potenti funzionalità, Perforce può essere difficile da configurare e richiedere un investimento significativo di tempo e risorse per il suo mantenimento. Questo è uno dei motivi per cui molte organizzazioni, compresa Google, hanno deciso di sviluppare i propri sistemi di gestione del codice come alternativa a Perforce.
Risorse e link utili:
| Nome Risorse | Descrizione | Link |
|---|---|---|
| Sito ufficiale di Perforce | Informazioni dettagliate su Perforce e i suoi prodotti | Perforce.com |
| Documentazione di Perforce | Manuale utente e documentazione tecnica di Perforce | Perforce Documentation |
| Blog di Perforce | Articoli e approfondimenti su Perforce e sviluppo software | Perforce Blog |
Perforce, pur essendo un ottimo strumento, può non essere la scelta giusta per ogni team o progetto. Assicurati di valutare attentamente le tue esigenze prima di decidere quale sistema di controllo delle versioni utilizzare.
Piper
Piper è un sistema di controllo delle versioni di codice sorgente sviluppato internamente da Google. Questo potente strumento è utilizzato per gestire l’immensa base di codice di Google, composta da oltre 2 miliardi di righe di codice, come menzionato nel precedente articolo.
Una delle caratteristiche più impressionanti di Piper è la sua capacità di gestire circa 40.000 commit al giorno, contribuiti da un esercito di oltre 10.000 ingegneri. Questo volume massiccio di dati e interazioni è gestito in modo efficiente grazie alla robusta architettura di Piper.
Piper non è solo un deposito di codice, ma supporta anche una serie di operazioni essenziali per la gestione e lo sviluppo del codice. Tra queste, il controllo delle versioni, la condivisione del codice, la gestione delle dipendenze, le modifiche atomiche e il refactoring su larga scala.
Per agevolare la collaborazione tra team e individui, Piper promuove la visibilità del codice. Ogni sviluppatore o team può avere la proprietà di una parte specifica del codice, ma l’intera base di codice è accessibile a tutti, migliorando la comprensione e la collaborazione.
Risorse e link utili:
| Risorse | Descrizione | Link |
|---|---|---|
| “Why Google Stores Billions of Lines of Code in a Single Repository” | Articolo che descrive come Google utilizza Piper | Link |
| “Scaling a Monolithic Codebase at Google” | Articolo che discute le pratiche di Google per scalare la sua base di codice con Piper | Link |
| “The Life of a Google Query” | Video che spiega come Google gestisce le query, incluse quelle all’interno di Piper | Link |
Al momento Piper non è un prodotto disponibile al pubblico. Gli sviluppatori esterni a Google devono fare affidamento su altri sistemi di controllo delle versioni, come Git, SVN o Mercurial.
Tricoder
Tricorder è un sistema automatico di revisione del codice sviluppato e utilizzato da Google. Prende il nome dal dispositivo di scansione multifunzionale dell’universo di Star Trek. Nel contesto dello sviluppo del software, Tricorder agisce come un aiuto critico per gli sviluppatori, automatizzando una parte del processo di revisione del codice.
Quando uno sviluppatore cerca di inviare (commit) nuovo codice al repository di Google, Tricorder entra in azione. Esegue una serie di controlli automatici sul codice e fornisce un feedback immediato allo sviluppatore. Questo feedback può includere avvertimenti su potenziali problemi di codice, come errori di sintassi, problemi di stile o problemi di performance.
Il valore di Tricorder risiede nella sua capacità di fornire feedback tempestivo e pertinente. Il sistema utilizza una varietà di analizzatori per esaminare il codice da diverse angolature, ognuno dei quali è progettato per rilevare specifici tipi di problemi. Inoltre, Tricorder è progettato per apprendere dai dati storici, migliorando continuamente la qualità e la pertinenza del feedback fornito.
L’obiettivo principale di Tricorder è migliorare la qualità del codice e facilitare la vita degli sviluppatori. Aiuta a identificare e risolvere i problemi prima che il codice venga integrato nel ramo principale del repository, riducendo così il tempo e lo sforzo necessari per risolvere i problemi in seguito.
Risorse e link utili:
| Risorse | Link |
|---|---|
| Documento di ricerca di Google su Tricorder | Link |
| Post del blog di Google su Tricorder | Link |
| Dettagli tecnici su Tricorder | Link |
Roise
Rosie è uno strumento di sviluppo di software utilizzato dagli ingegneri di Google per gestire operazioni di refactoring su larga scala, ottimizzazioni e pulizia del codice. Questo strumento gioca un ruolo fondamentale nel migliorare la qualità del codice e mantenere la base di codice organizzata e pulita.
Il refactoring del codice è un processo cruciale per mantenere il codice pulito, comprensibile e flessibile. Tuttavia, può diventare una sfida significativa quando si lavora su un grande progetto con miliardi di righe di codice, come è il caso per Google.
Ecco dove Rosie entra in gioco: questo potente strumento permette agli ingegneri di Google di dividere le modifiche in lotti più piccoli. Questo significa che invece di apportare un’enorme modifica in una sola volta, le modifiche vengono suddivise in più parti. Ogni lotto può poi essere esaminato e approvato da ciascun proprietario del codice prima di essere integrato nel progetto.
La possibilità di dividere le modifiche in piccoli lotti rende il processo di refactoring meno rischioso e più gestibile. Permette anche una revisione del codice più dettagliata e accurata, contribuendo a mantenere l’alto standard di qualità del codice che Google richiede.
Rosie è uno strumento interno di Google, non ci sono documenti o link pubblici disponibili. I link riportati nella tabella sopra sono risorse generali sul refactoring e sulla gestione del codice.
Supporto atomico per le transazioni
Il “supporto atomico per le transazioni” è un concetto che proviene dalla teoria dei database. Nell’ambito dei sistemi di controllo delle versioni, indica la capacità di apportare un insieme di modifiche come se fossero una singola operazione. In altre parole, tutte le modifiche vengono applicate o nessuna viene applicata, garantendo così la coerenza dei dati.
Per esempio, immagina di dover apportare modifiche a tre file differenti in modo che un’aggiunta di funzionalità al tuo software funzioni correttamente. Con il supporto atomico per le transazioni, tutte e tre le modifiche (ovvero, i commit) sarebbero considerate una singola transazione. Questo significa che se anche solo una delle modifiche non dovesse essere completata con successo (ad esempio a causa di un errore), allora nessuna delle modifiche verrebbe effettuata. In altre parole, o tutte le modifiche hanno successo o nessuna viene applicata. Questo mantiene la coerenza del codice e previene possibili errori o problemi di funzionamento.
CVS non supporta le transazioni atomiche, il che significa che, se stai cercando di fare commit di un gruppo di modifiche e qualcosa va storto a metà strada, alcune delle modifiche potrebbero essere applicate mentre altre no. Questo può portare a una situazione in cui il codice nel repository è in uno stato incoerente.
Al contrario, sistemi di controllo delle versioni più moderni come Git supportano le transazioni atomiche. Se tenti di fare commit di un insieme di modifiche con Git e qualcosa va storto, Git annullerà tutte le modifiche, lasciando il tuo codice in uno stato consistente.
Conclusione
La gestione del codice è una parte essenziale del ciclo di vita dello sviluppo software. Come abbiamo esplorato nel caso di Google, i metodi e gli strumenti adottati possono variare in base alle esigenze specifiche dell’organizzazione e del progetto. Google ha sviluppato e utilizzato una serie di strumenti interni come Piper, Tricorder e Rosie, insieme a sistemi di controllo delle versioni esterni come CVS e Perforce. Ogni strumento ha un suo ruolo specifico nel facilitare l’intero processo di sviluppo del codice.
Un concetto interessante da esplorare è l’idea di “modifiche atomiche”. L’atomizzazione delle modifiche permette ai team di dividere un’ampia modifica in una serie di cambiamenti più piccoli, facilitando così il processo di revisione del codice e riducendo i rischi associati all’integrazione di nuove modifiche.
Ma non dimentichiamo che, alla fine, gli strumenti sono solo mezzi per raggiungere un obiettivo. Il vero cuore dello sviluppo del software sono gli sviluppatori stessi e le metodologie che scelgono di adottare. Quindi, indipendentemente dall’approccio o dagli strumenti che utilizziamo, è essenziale continuare a imparare, adattarsi e migliorare.
Ti lascio con alcune domande su cui riflettere: Come potrebbe il tuo team beneficiare di un approccio simile a quello adottato da Google? Esistono strumenti o metodologie che potreste adottare o adattare per migliorare il vostro flusso di lavoro? Ricorda, ogni team e progetto ha esigenze uniche, e la chiave è trovare la soluzione che funziona meglio per voi.