Perché scegliere Git per la tua organizzazione
Il passaggio da un sistema di controllo delle versioni centralizzato a Git cambia il modo in cui il team di sviluppo crea il software. E, se la tua azienda si affida a un software proprietario per le applicazioni mission-critical, la modifica del flusso di lavoro di sviluppo ha un impatto generale.
Git per gli sviluppatori
Flusso di lavoro del branch di funzioni
Uno dei maggiori vantaggi di Git sono le sue funzionalità di creazione di branch. A differenza dei sistemi di controllo delle versioni centralizzati, i branch Git sono economici e facili da sottoporre a merge. Ciò agevola il flusso di lavoro del branch di funzioni ampiamente utilizzato da molti utenti di Git.
I branch di funzioni forniscono un ambiente isolato per ogni modifica da apportare alla base di codice. Quando uno sviluppatore vuole iniziare a lavorare su qualcosa, non importa se di grandi o piccole dimensioni, crea un nuovo branch. In questo modo, il branch principale contiene sempre codice di qualità di produzione.
L'uso dei branch di funzioni non è solo più affidabile rispetto alla modifica diretta del codice di produzione, ma offre anche vantaggi organizzativi. Questi branch consentono di rappresentare il lavoro di sviluppo con la stessa granularità del backlog Agile. Ad esempio, puoi implementare una policy che prevede l'indirizzamento di ogni ticket Jira al relativo branch di funzioni.
materiale correlato
Scheda di riferimento rapido di Git
Scopri la soluzione
Impara a utilizzare Git con Bitbucket Cloud
Sviluppo distribuito
In SVN, ogni sviluppatore riceve una copia di lavoro che rimanda a un unico repository centrale. Git, tuttavia, è un sistema di controllo delle versioni distribuito. Invece di una copia di lavoro, ogni sviluppatore riceve un proprio repository locale che comprende la cronologia completa dei commit.
L'avere una cronologia locale completa velocizza le prestazioni di Git, poiché significa che non è necessaria una connessione di rete per creare commit, ispezionare le versioni precedenti di un file o eseguire differenze tra i commit.
Lo sviluppo distribuito semplifica anche la scalabilità del team di progettazione. Se qualcuno danneggia il branch di produzione in SVN, gli altri sviluppatori non possono inserire le modifiche finché il problema non viene risolto. Con Git, questo tipo di blocco non esiste. Tutti possono continuare a svolgere il proprio lavoro nei propri repository locali.
E, come accade con i branch di funzioni, lo sviluppo distribuito crea un ambiente più affidabile. Anche se uno sviluppatore cancella il proprio repository, può semplicemente clonare quello di qualcun altro e ricominciare da capo.
Pull request
Molti strumenti di gestione del codice sorgente, come Bitbucket, potenziano le funzionalità di base di Git con le richieste di pull. Con le richieste di pull, si può chiedere a un altro sviluppatore di eseguire il merge di uno dei propri branch nel suo repository. Ciò non solo semplifica il monitoraggio delle modifiche ai coordinatori del progetto, ma consente anche agli sviluppatori di confrontarsi sul loro lavoro prima di integrarlo con il resto della base di codice.
Le pull request sono estremamente versatili, non essendo altro che un thread di commenti collegato a un branch di funzioni. Se uno sviluppatore si trova bloccato su un problema grave, può aprire una pull request per chiedere aiuto al resto del team. Oppure, gli sviluppatori junior possono trattare le pull request come una revisione del codice formale per assicurarsi di non danneggiare l'intero progetto.
Community
In molti ambienti, Git è diventato il sistema di controllo delle versioni predefinito per i nuovi progetti. Se il tuo team utilizza Git, è probabile che i nuovi assunti conoscano già lo sviluppo distribuito e che quindi non sarà necessario formarli sul flusso di lavoro seguito dal team.
Inoltre, Git è molto popolare tra i progetti open source. Ciò significa che è facile sfruttare le librerie di terze parti e incoraggiare gli altri ad eseguire un fork del proprio codice open source.
Ciclo di rilascio più rapido
Il risultato finale di branch di funzioni, sviluppo distribuito, pull request e una community stabile è un ciclo di rilascio più rapido. Queste funzionalità facilitano un flusso di lavoro Agile in cui gli sviluppatori sono incoraggiati a condividere modifiche minori con maggiore frequenza. A loro volta, le modifiche possono essere fatte avanzare nella pipeline di distribuzione più velocemente rispetto ai rilasci monolitici comuni nei sistemi di controllo delle versioni centralizzati.
Come ci si potrebbe aspettare, Git si integra molto bene con gli ambienti di continuous integration e continuous delivery. Gli hook Git consentono di eseguire gli script quando si verificano determinati eventi all'interno di un repository, per darti la possibilità di automatizzare la distribuzione come preferisci. Puoi persino compilare o distribuire codice da branch specifici su server diversi.
Ad esempio, è consigliabile configurare Git sulla distribuzione del commit più recente dal branch develop a un server di test ogni volta che qualcuno vi esegue il merge di una pull request. Unire questo tipo di automazione di build alla peer review significa che puoi avere la massima fiducia nel tuo codice mentre questo passa dall'ambiente di sviluppo a quello di staging, fino a quello di produzione.
Git per il marketing
Per comprendere l'impatto che il passaggio a Git ha sulle attività di marketing aziendali, immagina che il team di sviluppo abbia tre diverse modifiche da completare nelle prossime settimane:
- L'intero team sta portando a termine una funzionalità rivoluzionaria su cui ha lavorato negli ultimi 6 mesi.
- Mary sta implementando una funzione più piccola e non correlata che ha un impatto solo sui clienti esistenti.
- Rick sta apportando alcuni aggiornamenti necessari all'interfaccia utente.
Se impieghi un flusso di lavoro di sviluppo tradizionale basato su un VCS centralizzato, tutte queste modifiche verrebbero probabilmente raggruppate in un unico rilascio. Il team di marketing può preparare solo un annuncio incentrato principalmente sulla funzione rivoluzionaria e il potenziale di marketing degli altri due aggiornamenti viene effettivamente ignorato.
Il ciclo di sviluppo più breve agevolato da Git rende molto più facile suddividere tali modifiche in singoli rilasci. In questo modo, gli esperti di marketing avranno molte più notizie da divulgare e con maggiore frequenza. Nello scenario riportato sopra, il team di marketing può costruire tre campagne che ruotano attorno a ciascuna funzione e quindi mirare a segmenti di mercato molto specifici.
Ad esempio, il team potrebbe preparare una grande iniziativa pubblicitaria per la funzione rivoluzionaria, un post sul blog aziendale e una newsletter per la funzione su cui sta lavorando Mary e alcuni guest post sulla teoria sull'esperienza utente di Rick da inviare a blog di progettazione esterni. Tutte queste attività possono essere sincronizzate con un rilascio separato.
Git per la gestione dei prodotti
I vantaggi di Git per la gestione del prodotto sono più o meno gli stessi di quelli per il marketing. Rilasci più frequenti significano feedback dei clienti più frequenti e aggiornamenti più rapidi in risposta a tali feedback. Invece di aspettare il rilascio successivo tra 8 settimane, puoi inviare una soluzione ai clienti con la stessa rapidità con cui gli sviluppatori possono scrivere il codice.
Il flusso di lavoro del branch di funzioni offre inoltre flessibilità quando cambiano le priorità. Ad esempio, se sei a metà di un ciclo di rilascio e vuoi posticipare una funzione al posto di un'altra più urgente, non ci sono problemi. Quella funzione iniziale può rimanere nel proprio branch finché il team di progettazione non avrà il tempo di lavorarci.
Questa stessa funzionalità semplifica la gestione di progetti di innovazione, beta test e prototipi rapidi come basi di codice indipendenti.
Git per i designer
I branch di funzioni si prestano alla prototipazione rapida. Sia che i designer dedicati all'esperienza o all'interfaccia utente vogliano implementare un flusso utente completamente nuovo o semplicemente sostituire alcune icone, tramite l'estrazione di un nuovo branch possono avere un ambiente sandbox in cui effettuare diversi test. In questo ambiente, i designer possono vedere come appariranno le loro modifiche in una copia realmente funzionante del prodotto senza il rischio di interrompere le funzionalità esistenti.
Racchiudendo in questo modo le modifiche all'interfaccia utente, diventa semplice presentare gli aggiornamenti agli altri stakeholder. Ad esempio, se il Director of Engineering vuole vedere su cosa sta lavorando il team di progettazione, tutto ciò che deve fare è estrarre il branch corrispondente.
Le pull request consentono di fare un ulteriore passo avanti perché forniscono un luogo formale in cui le parti interessate possono discutere della nuova interfaccia. I designer possono apportare le modifiche necessarie e i commit risultanti verranno visualizzati nella pull request. Questo processo richiede la partecipazione di tutti di al processo di iterazione.
Forse la parte migliore della prototipazione con i branch è che è tanto facile sottoporre a merge le modifiche in produzione quanto lo è eliminarle. Non c'è alcuna pressione per nessuna delle due operazioni e questo incoraggia i designer e gli sviluppatori dell'interfaccia utente a sperimentare avendo la sicurezza che soltanto le idee migliori raggiungeranno i clienti.
Git per l'assistenza clienti
I team di assistenza clienti e di successo aziendale hanno spesso una visione diversa degli aggiornamenti rispetto ai responsabili di prodotto. Quando un cliente li chiama, di solito è perché ha qualche tipo di problema. Se tale problema è causato dal software dell'azienda, è necessario inviare una correzione del bug il prima possibile.
Il ciclo di sviluppo semplificato di Git evita di posticipare le correzioni dei bug al successivo rilascio monolitico. Uno sviluppatore può correggere il problema e inviarlo direttamente in produzione. Correzioni più rapide si traducono in clienti più soddisfatti e in un numero inferiore di ticket di assistenza ripetuti. I membri del team di assistenza possono informare subito i clienti che il bug è già stato risolto, invece di rassicurarli che si occuperanno subito di risolverlo!
Git per le risorse umane
In un certo senso, la scelta delle persone da assumere è determinata dal flusso di lavoro di sviluppo software. È sempre utile assumere tecnici che abbiano familiarità con le tecnologie e i flussi di lavoro impiegati nell'azienda, ma l'uso di Git offre anche altri vantaggi.
I dipendenti sono attratti dalle aziende che offrono opportunità di crescita professionale, e imparare a utilizzare Git in organizzazioni di grandi e piccole dimensioni è un vantaggio per qualsiasi programmatore. Scegliendo Git come sistema di controllo delle versioni, stai decidendo di attrarre sviluppatori lungimiranti nella tua azienda.
Git gli addetti alla gestione del budget
Git è sinonimo di efficienza. Per gli sviluppatori, a differenza dei sistemi di controllo delle versioni centralizzati, elimina il tempo sprecato a trasferire i commit sulla connessione di rete, così come le ore di lavoro necessarie per integrare le modifiche. Per quanto riguarda gli sviluppatori junior, offre loro un ambiente di lavoro sicuro per impiegare al meglio le loro competenze. Tutto ciò influisce sulle prestazioni generali del reparto tecnico.
Ma non dimenticare che queste efficienze si estendono anche al di fuori del team di sviluppo. Con Git, il team di marketing non deve investire energie nella creazione di materiali collaterali per funzioni poco richieste e i designer hanno la possibilità di testare nuove interfacce sul prodotto reale con un minimo di sovraccarico. Git consente inoltre di rispondere immediatamente alle lamentele dei clienti.
Essere agili significa scoprire cosa funziona il più rapidamente possibile, amplificare gli sforzi che portano risultati positivi ed eliminare quelli con risultati negativi. Git funge da moltiplicatore di tutte le attività aziendali garantendo che ogni reparto svolga il proprio lavoro in modo più efficiente.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Blog di Bitbucket
Percorso di apprendimento DevOps
