Sviluppo basato su trunk e Git Flow

Per sviluppare software di qualità, dobbiamo essere in grado di tenere traccia di tutte le modifiche e, se necessario, annullarle. I sistemi di controllo della versione ricoprono quel ruolo monitorando la cronologia del progetto e aiutando a unire le modifiche apportate da più persone. Accelerano notevolmente il lavoro e ci danno la possibilità di trovare i bug più facilmente.

Inoltre, lavorare in team distribuiti è possibile principalmente grazie a questi strumenti. Consentono a più persone di lavorare su diverse parti di un progetto contemporaneamente e in seguito di unire i loro risultati in un unico prodotto. Diamo un'occhiata più da vicino ai sistemi di controllo della versione e spieghiamo come sono nati lo sviluppo basato su trunk e il flusso Git.

Come i sistemi di controllo della versione hanno cambiato il mondo

Prima della creazione dei sistemi di controllo delle versioni, le persone facevano affidamento sul backup manuale delle versioni precedenti dei progetti. Stavano copiando manualmente i file modificati per incorporare il lavoro di più sviluppatori sullo stesso progetto.

Costava molto tempo, spazio su disco rigido e denaro.

Quando osserviamo la storia, possiamo distinguere ampiamente tre generazioni di software di controllo della versione.

Diamo un'occhiata a loro:

Notiamo che man mano che i sistemi di controllo della versione maturano, c'è la tendenza ad aumentare la capacità di lavorare su progetti in parallelo.

Una delle modifiche più rivoluzionarie è stata invece il passaggio dal blocco dei file all'unione delle modifiche. Ha consentito ai programmatori di lavorare in modo più efficiente.

Un altro notevole miglioramento è stata l'introduzione dei sistemi distribuiti. Git è stato uno dei primi strumenti a incorporare questa filosofia. Ha letteralmente permesso al mondo open source di prosperare. Git consente agli sviluppatori di copiare l'intero repository, in un'operazione chiamata fork, e di introdurre le modifiche desiderate senza doversi preoccupare di conflitti di unione.

Successivamente, possono avviare una richiesta pull per unire le modifiche apportate al progetto originale. Se lo sviluppatore iniziale non è interessato a incorporare tali modifiche da altri repository, può trasformarle autonomamente in progetti separati. Tutto è possibile grazie al fatto che non esiste il concetto di stoccaggio centralizzato.

Stili di sviluppo

Al giorno d'oggi, il sistema di controllo della versione più popolare è sicuramente Git, con una quota di mercato di circa il 70 percento nel 2016.

Git è stato reso popolare con l'ascesa di Linux e della scena open source in generale. Anche GitHub, attualmente lo storage online più popolare per i progetti pubblici, ha contribuito notevolmente alla sua prevalenza. Dobbiamo a Git l'introduzione di richieste pull facili da gestire.

In parole povere, le richieste pull sono richieste create da uno sviluppatore di software per combinare le modifiche che ha creato con il progetto principale. Include un processo di revisione di tali modifiche. I revisori possono inserire commenti su ogni aspetto che ritengono possa essere migliorato o ritenuto non necessario.

Dopo aver ricevuto il feedback, il creatore può rispondere ad esso, creando una discussione o semplicemente seguirlo e modificare il proprio codice di conseguenza.

Git è semplicemente uno strumento. Puoi usarlo in molti modi diversi. Attualmente, i due stili di sviluppo più popolari che puoi incontrare sono il flusso Git e lo sviluppo basato su trunk. Molto spesso, le persone hanno familiarità con uno di questi stili e potrebbero trascurare l'altro.

Diamo un'occhiata più da vicino a entrambi e impariamo come e quando dovremmo usarli.

Git flusso

Nel modello di sviluppo del flusso Git, hai un ramo di sviluppo principale con accesso rigoroso ad esso. Viene spesso chiamato ramo di develop .

Gli sviluppatori creano rami di funzionalità da questo ramo principale e lavorano su di essi. Una volta terminato, creano richieste pull. Nelle richieste pull, altri sviluppatori commentano le modifiche e possono avere discussioni, spesso piuttosto lunghe.

Ci vuole del tempo per concordare una versione finale delle modifiche. Una volta concordata, la richiesta pull viene accettata e unita al ramo principale. Una volta deciso che il ramo principale ha raggiunto una maturità sufficiente per essere rilasciato, viene creato un ramo separato per preparare la versione finale. L'applicazione di questo ramo viene testata e vengono applicate correzioni di bug fino al momento in cui è pronta per essere pubblicata per gli utenti finali. Una volta fatto, uniamo il prodotto finale al ramo master e lo tagghiamo con la versione di rilascio. Nel frattempo, è possibile sviluppare nuove funzionalità sul ramo di develop .

Di seguito, puoi vedere il diagramma di flusso Git, che illustra un flusso di lavoro generale:

Uno dei vantaggi di Git flow è il controllo rigoroso. Solo gli sviluppatori autorizzati possono approvare le modifiche dopo averle esaminate da vicino. Garantisce la qualità del codice e aiuta a eliminare i bug in anticipo.

Tuttavia, è necessario ricordare che può anche essere un enorme svantaggio. Crea un imbuto che rallenta lo sviluppo del software. Se la velocità è la tua preoccupazione principale, allora potrebbe essere un problema serio. Le caratteristiche sviluppate separatamente possono creare rami di lunga durata che potrebbero essere difficili da combinare con il progetto principale.

Inoltre, le richieste pull focalizzano la revisione del codice esclusivamente sul nuovo codice. Invece di guardare il codice nel suo insieme e lavorare per migliorarlo in quanto tale, controllano solo le modifiche introdotte di recente. In alcuni casi, potrebbero portare a un'ottimizzazione prematura poiché è sempre possibile implementare qualcosa con prestazioni più rapide.

Inoltre, le richieste pull potrebbero portare a un'ampia microgestione, in cui lo sviluppatore principale gestisce letteralmente ogni singola riga di codice. Se hai sviluppatori esperti di cui ti puoi fidare, possono gestirlo, ma potresti sprecare il loro tempo e le loro abilità. Può anche demotivare gravemente gli sviluppatori.

Nelle organizzazioni più grandi, la politica dell'ufficio durante le richieste pull è un'altra preoccupazione. È ipotizzabile che le persone che approvano le richieste pull possano utilizzare la loro posizione per impedire di proposito a determinati sviluppatori di apportare modifiche alla base di codice. Potrebbero farlo per mancanza di fiducia, mentre alcuni potrebbero abusare della loro posizione per regolare i conti personali.

Pro e contro di Git Flow

Come puoi vedere, eseguire richieste pull potrebbe non essere sempre la scelta migliore. Dovrebbero essere usati solo dove appropriato.

Quando funziona meglio Git Flow?

• Quando esegui un progetto open source.
  Questo stile viene dal mondo open source e funziona meglio lì. Dal momento che tutti possono contribuire, si desidera avere un accesso molto rigoroso a tutte le modifiche. Vuoi essere in grado di controllare ogni singola riga di codice, perché francamente non puoi fidarti delle persone che contribuiscono. Di solito, quelli non sono progetti commerciali, quindi la velocità di sviluppo non è un problema.

• Quando hai molti sviluppatori junior.
  Se lavori principalmente con sviluppatori junior, allora vuoi avere un modo per controllare da vicino il loro lavoro. Puoi dare loro più suggerimenti su come fare le cose in modo più efficiente e aiutarli a migliorare le loro abilità più velocemente. Le persone che accettano richieste pull hanno un controllo rigoroso sulle modifiche ricorrenti in modo da poter prevenire il deterioramento della qualità del codice.

  

• Quando hai un prodotto consolidato.
  Questo stile sembra funzionare bene anche quando hai già un prodotto di successo. In questi casi, l'attenzione si concentra solitamente sulle prestazioni dell'applicazione e sulle capacità di carico. Questo tipo di ottimizzazione richiede modifiche molto precise. Di solito, il tempo non è un vincolo, quindi questo stile funziona bene qui. Inoltre, le grandi imprese si adattano perfettamente a questo stile. Hanno bisogno di controllare ogni cambiamento da vicino, dal momento che non vogliono rompere il loro investimento multimilionario.

Quando Git Flow può causare problemi?

• Quando stai appena iniziando.
  Se stai appena iniziando, allora Git flow non fa per te. È probabile che tu voglia creare rapidamente un prodotto minimo praticabile. L'esecuzione di richieste pull crea un enorme collo di bottiglia che rallenta notevolmente l'intero team. Semplicemente non puoi permettertelo. Il problema con il flusso Git è il fatto che le richieste pull possono richiedere molto tempo. Semplicemente non è possibile fornire un rapido sviluppo in questo modo.

• Quando è necessario scorrere rapidamente.
  Una volta raggiunta la prima versione del tuo prodotto, molto probabilmente dovrai ruotarla alcune volte per soddisfare le esigenze dei tuoi clienti. Anche in questo caso, più branch e richieste pull riducono drasticamente la velocità di sviluppo e non sono consigliati in questi casi.

• Quando lavori principalmente con sviluppatori senior.
  Se il tuo team è composto principalmente da sviluppatori senior che hanno lavorato tra loro per un periodo di tempo più lungo, non hai davvero bisogno della suddetta microgestione delle richieste pull. Ti fidi dei tuoi sviluppatori e sai che sono professionisti. Lascia che facciano il loro lavoro e non rallentarli con tutta la burocrazia del flusso Git.

Flusso di lavoro di sviluppo basato su trunk

Nel modello di sviluppo basato su trunk, tutti gli sviluppatori lavorano su un unico ramo con accesso aperto ad esso. Spesso è semplicemente il ramo master . Impegnano il codice e lo eseguono. È semplicissimo.

In alcuni casi, creano rami di caratteristiche di breve durata. Una volta che il codice sul loro ramo viene compilato e superato tutti i test, lo uniscono direttamente a master . Garantisce che lo sviluppo sia veramente continuo e impedisce agli sviluppatori di creare conflitti di unione difficili da risolvere.

Diamo un'occhiata al flusso di lavoro di sviluppo basato su trunk.

L'unico modo per rivedere il codice in un tale approccio è eseguire una revisione completa del codice sorgente. Di solito, le lunghe discussioni sono limitate. Nessuno ha un controllo rigoroso su ciò che viene modificato nella base del codice sorgente, ecco perché è importante disporre di uno stile di codice applicabile. Gli sviluppatori che lavorano in questo stile dovrebbero essere esperti in modo da sapere che non abbasseranno la qualità del codice sorgente.

Questo stile di lavoro può essere eccezionale quando lavori con un team di sviluppatori software esperti. Consente loro di introdurre nuovi miglioramenti rapidamente e senza inutili burocrazia. Mostra loro anche che ti fidi di loro, poiché possono introdurre il codice direttamente nel ramo master . Gli sviluppatori in questo flusso di lavoro sono molto autonomi: consegnano direttamente e vengono controllati i risultati finali nel prodotto funzionante. C'è sicuramente molto meno microgestione e possibilità per la politica d'ufficio in questo metodo.

Se, d'altra parte, non hai una squadra esperta o non ti fidi di loro per qualche motivo, non dovresti usare questo metodo, dovresti invece scegliere Git flow. Ti farà risparmiare inutili preoccupazioni.

Pro e contro dello sviluppo basato su trunk

Diamo un'occhiata più da vicino a entrambi i lati del costo: gli scenari migliori e peggiori.

Quando funziona meglio lo sviluppo basato su trunk?

• Quando stai appena iniziando.
  Se stai lavorando al tuo prodotto minimo praticabile, allora questo stile è perfetto per te. Offre la massima velocità di sviluppo con la minima formalità. Poiché non ci sono richieste pull, gli sviluppatori possono fornire nuove funzionalità alla velocità della luce. Assicurati solo di assumere programmatori esperti.

• Quando è necessario scorrere rapidamente.
  Una volta che hai raggiunto la prima versione del tuo prodotto e hai notato che i tuoi clienti vogliono qualcosa di diverso, non pensarci due volte e usa questo stile per cambiare direzione. Sei ancora nella fase di esplorazione e devi poter cambiare il tuo prodotto il più velocemente possibile.

• Quando lavori principalmente con sviluppatori senior.
  Se il tuo team è composto principalmente da sviluppatori senior, dovresti fidarti di loro e lasciare che facciano il loro lavoro. Questo flusso di lavoro offre loro l'autonomia di cui hanno bisogno e consente loro di esercitare la padronanza della propria professione. Dai loro uno scopo (compiti da portare a termine) e osserva come cresce il tuo prodotto.

Quando lo sviluppo basato su trunk può causare problemi?

• Quando esegui un progetto open source.
  Se stai eseguendo un progetto open source, Git flow è l'opzione migliore. Hai bisogno di un controllo molto rigoroso sulle modifiche e non puoi fidarti dei contributori. Dopotutto, chiunque può contribuire. Compresi i troll online.

• Quando hai molti sviluppatori junior.
  Se assumi principalmente sviluppatori junior, è un'idea migliore controllare strettamente ciò che stanno facendo. Richieste pull rigorose li aiuteranno a migliorare le proprie abilità e a trovare potenziali bug più rapidamente.

• Quando hai stabilito un prodotto o gestisci team di grandi dimensioni.
  Se hai già un prodotto di successo o gestisci team di grandi dimensioni in una grande azienda, allora Git flow potrebbe essere un'idea migliore. Vuoi avere un controllo rigoroso su ciò che sta accadendo con un prodotto consolidato del valore di milioni di dollari. Probabilmente, le prestazioni dell'applicazione e le capacità di carico sono le cose più importanti. Questo tipo di ottimizzazione richiede modifiche molto precise.

Usa lo strumento giusto per il lavoro giusto

Come ho detto prima, Git è solo uno strumento. Come ogni altro strumento, deve essere utilizzato in modo appropriato.

Git flow gestisce tutte le modifiche tramite richieste pull. Fornisce un controllo rigoroso dell'accesso a tutte le modifiche. È ottimo per progetti open source, grandi imprese, aziende con prodotti affermati o un team di sviluppatori junior inesperti. Puoi controllare in sicurezza cosa viene introdotto nel codice sorgente. D'altra parte, potrebbe portare a un'ampia microgestione, controversie che coinvolgono la politica d'ufficio e uno sviluppo significativamente più lento.

Lo sviluppo basato su trunk offre ai programmatori piena autonomia ed esprime maggiore fiducia in loro e nel loro giudizio. L'accesso al codice sorgente è gratuito, quindi devi davvero essere in grado di fidarti del tuo team. Fornisce un'eccellente velocità di sviluppo del software e riduce i processi. Questi fattori lo rendono perfetto quando si creano nuovi prodotti o si sposta un'applicazione esistente in una direzione completamente nuova. Funziona a meraviglia se lavori principalmente con sviluppatori esperti.

Tuttavia, se lavori con programmatori junior o persone di cui non ti fidi completamente, Git flow è un'alternativa molto migliore.

Dotato di queste conoscenze, spero che sarai in grado di scegliere il flusso di lavoro che si adatta perfettamente al tuo progetto.