Non sai scegliere tra TFVC, ex TFS, e Git su DevOps? Scoprilo qui

Se lavori da tempo con tecnologie Microsoft difficilmente non conoscerai Team Foundation Service (TFS); è possibile invece che tu non abbia mai sentito parlare di Git. In questo articolo ti parlo del perché dovresti usare questi due strumenti insieme e quali vantaggi ti stai perdendo non facendolo.

Cos'è Team Foundation Server (TFS)

TFS è un server per la gestione del ciclo di vita del del software a partire dalla raccolta dei requisiti, per passare allo sviluppo del codice, i test, fino alla messa in produzione della funzionalità, per poi continuare con la manutenzione.

Il vero vantaggio di questo prodotto é che permette di collegare tutte queste fasi dando visibilità, per ogni evento accaduto circa una funzionalità, della sequenze delle operazioni accadute su di essa e che hanno portato a quel preciso stato.

Mi spiego con un esempio. Immagina un bug in produzione. Con TFS puoi risalire facilmente al requisito a cui quel bug si riferisce ed arrivare così al pezzo di codice sviluppato originariamente per implementarlo, comprese tutte le eventuali modifiche. Non solo: puoi scoprire se lo stesso bug si è già presentato in passato (regressione) e i test (automatici e non) che sono stati eseguiti per verificarlo. Insomma, conoscendo tutta la storia della funzionalità e del bug, lo sviluppatore ha tutti gli strumenti a disposizione per individuare rapidamente il malfunzionamento e correggerlo con la tranquillità di non introdurre altri bug durante il fix. Aggiornato il codice, TFS può notificare i tester che una nuova release del software incluso dell'anomalia corretta, è pronta per essere sottoposta ai test di qualità e successivamente rilasciata in produzione in caso di esito positivo dei test.

Tra il 2018 e il 2019, TFS ha cambiato nome diventando Azure DevOps Service nella versione Cloud, e Azure DevOps Server 2019 nella versione On-Premises.

Cos’è Team Foundation Version Control (TFVC)

La prima versione di TFS rilasciata nel 2006, ha introdotto un nuovo strumento di gestione del versionamento del codice sorgente sviluppato appositamente per questo prodotto: Team Foundation Version Control. TFVC è il prodotto che di fatto ha sostituito quello che era lo strumento Microsoft per gestire il codice sorgente fino a quel momento: Source Safe.

TFVC poteva essere utilizzato senza gli altri servizi di TFS, ma i maggiori vantaggi li raggiungeva se integrato con quest’ultimo. perché? Te lo racconto subito. Grazie all’integrazione di TFS, TFVC può essere esteso con dei plugin (checkin policy) che rifiutano il checkin del proprio codice locale sul server se non sono state soddisfatti determinati requisiti. Ad esempio, TFVC può bloccare il checkin nel caso lo sviluppatore non abbia associato al checkin il requisito che quel codice implementa: in questo modo c’è la garanzia che ogni requisito o bug è correlato allo storico delle modifiche del codice sorgente.

Oggi TFVC non è più l’unica scelta possibile come source control system da usare con Azure DevOps. Infatti, da TFS 2013 è stato introdotto il supporto nativo di Git.

Cos’è Git

Git è il server di versionamento del codice sorgente più in diffuso ed è nato da Linus Torvalds, il creatore di linux.

È il sistema più utilizzato in assoluto ed è la base di tutti i più importanti servizi cloud di hosting del codice sorgente. Infatti Git deve la sua popolarità (anche) a GitHub, hosting di progetti software che ha sempre rivolto particolare attenzione alle iniziative open source. GitHub è utilizzato dalle più grandi aziende del pianeta come Google, Microsoft Apple, Nasa, Facebook e Twitter ed è stato acquisito nel 2018 da Microsoft: questo è un chiaro segno di come Microsoft punti sull’open source.

Le differenze tra TFVC e Git

La maggior parte degli altri strumenti di versionamento del codice sul mercato, incluso TFVC sincronizzano il codice locale contenuto in una cartella con il server. La creazione delle versioni del codice avviene unicamente sul server.

Ciò che differenzia Git da tutti gli altri è che il versionamento del codice avviene in locale; il server remoto è utilizzato solo per sincronizzare ed integrare i repository locale gestendo eventuali conflitti. Se sei curioso, noterai che ogni directory sul tuo pc che contiene un repository Git include una directory “.git”: qui trovare tutti i file storicizzati delle modifiche e i metadati per ricostruire la situazione ad ogni momento di vita del progetto. Proprio per questa peculiarità dell’esistenza di un repository locale, la terminologia di Git è molto differente da quella di TFVC (ed egli altri prodotti simili). Infatti TFVC ha un vocabolario in cui le operazioni principali sono due:

• il check out prende l’ultima versione del codice sorgente sul server ed aggiorna il codice locale gestendo eventuali modifiche e notificando possibili conflitti
• il check in prende le modifiche apportate al codice locale ed invia le modifiche al server che - in assenza di conflitti - sono storicizzate generando quello che è chiamato change set

Git ha vocabolario è più ampio. Le modifiche sono versionate in locale attraverso un’operazione chiamata “commit” che genera un identificativo univoco del change set della modifica. Attraverso questo identificativo (il cui formato è un hash) sarà possibile riferirsi e reperire sia in locale che sul server (previa sincronizzazione) il set di modifiche.

Ogni volta che vogliamo sincronizzare i repository locale con quello remoto dobbiamo eseguire un’operazione di “push". In maniera duale, l’operazione “pull” trasferisce i changeset remoti  non presenti il locale, aggiornando la cartella di lavoro con la situazione corrente. Durante l’operazione di “push” Git è molto restrittivo perché blocca in modo preventivo l’operazione nel caso in cui il proprio codice non è allineato con tutto ciò che c'è sul sul server.

Perché usare Git?

La terminologia di Git è sicuramente meno consueta rispetto a quanto siamo stati abituati in passato, ed a un primo sguardo può sembrare più complessa generando una sensazione di smarrimento iniziale.

Una volta superato il primo scoglio Git offre innumerevoli vantaggi. Ad esempio, se sviluppi un progetto o parte di esso in totale autonomia ed hai bisogno di un repository per mantenere la storia delle tue modifiche, usare Git e il suo repository locale, ti permette di mantenere tutti i vantaggi di un sistema di versionamento del tuo codice senza installare un server remoto o acquistare dell’hosting risparmiando così in infrastruttura.

In questo scenario come faccio per i backup?

Semplice: se già utilizzi servizi di dischi remoti come Dropbox o Google Drive, ti basta aggiungere la tua cartella sotto il controllo di questi servizi e il tuo codice sarà al sicuro. Ti ricordo infatti che un repository Git, compreso della configurazione e di tutta la storia delle modifiche è interamente contenuto nella directory del tuo progetto.

Proseguiamo con i vantaggi.

Avere un repository locale ti permette di fare tutte le prove di cui necessiti senza stress e con la tranquillità che - nel caso il risultato finale non ti soddisfi - puoi ritornare allo stato precedente con pochi semplici passi proprio come se avessi in mano una macchina del tempo.

Immagina di dover fare un merge complesso o un ricovery parziale di una parte di modifiche fatte in precedenza o semplicemente di voler provare un comando di Git. L’unica accortezza che devi avere è di non fare push delle modifiche sul server remoto - qualora tu ne abbia uno - fino a che non sei sicuro delle modifiche. In tutti gli altri casi, le operazioni fatte in locale sono facilmente recuperabili.

In altri scenari (spike, prove di refactoring, codice esplorativo...) potrebbe servirti creare una branch in locale e decidere successivamente se e quando crearla anche in remoto sul server. Infatti potresti decidere di promuovere il codice consolidando sulla branch principale le modifiche e cancellare la branch creata senza lasciare alcuna traccia sul server oppure potresti eliminare la branch in locale senza alcuna operazione di consolidamento perché hai deciso che l’esplorazione sul codice che hai tentato non ha portato a nessun risultato significativo.

In definitiva Git è un prodotto con una curva di apprendimento iniziale più elevata ma estremamente potente. Una volta imparato in modo approfondito e conosciute le proprie sfaccettature permette di eseguire operazioni molto potenti oltre ad avere il controllo minuzioso e puntuale dello stato presente e passato del tuo repository.

I vantaggi di Git negli scenari di continuous deployment

Come abbiamo visto, TFVC per funzionare deve essere collegato ad un server. Diversamente Git non richiede un server remoto e può essere utilizzato come server di versionamento del codice sorgente locale.

C’è in realtà un altro grosso vantaggio di Git: è possibile sincronizzare un repository locale con più server remoti.

Benchè a prima vista questa possa sembrare una feature insolita è molto comoda in ambienti di rilascio continuo. Immagina di avere un repository remoto per lo sviluppo del codice sorgente da usare per sviluppare e integrare le funzionalità del progetto. Immagina ora di avere anche un secondo repository remoto utilizzato solamente per i deploy. Perché?

Ogni volta che una versione del codice è pronta per essere rilasciata in un ambiente (pre produzione o produzione), lo sviluppatore fa un push sul secondo server git remoto che fa partire un trigger. Al frigger è agganciata una procedura automatica di deploy del codice contenuto su quest’ultimo server remoto.

Risultato?

Hai un server remoto per lo sviluppo giornaliero del codice su cui gli sviluppatori possono storicizzare liberamente le proprie modifiche ed un secondo server che sarà aggiornato solo quando si desidera lanciare un nuovo processo di deploy. Bello vero?

Ti dico di più, molti servizi di hosting di cloud computing funzionano esattamente con questo meccanismo: Heroku ne è un esempio ma ne esistono molti altri.

Serve imparare tutte le funzionalità di Git?

Ti ho parlato di alcune funzionalità di Git e di alcuni scenari che puoi coprire con questo strumento.

Tutti gli sviluppatori hanno bisogno di questo livello di controllo? Soprattutto, è necessario in ogni momento avere a che fare con questa complessità?

No, spesso lo sviluppatore medio del tuo team dovrà eseguire solo le operazioni che faceva con TFVC (checkin e checkout sul server) lasciando a casi saltuari la necessità di eseguire operazioni particolari.

Oltre ad essere molto potente Git ha un altro grande vantaggio: è estremamente configurabile. Ad esempio Git mette a disposizione un comando di alias che permette di creare comandi personalizzati per te e per il tuo team. Generalmente si usano gli alias per dare dei nomi semplici e facilmente ricordabili per operazioni complesse formate da una cocatenazione di comandi singoli, oppure per operazioni che lo sviluppatore esegue nella sua routine e vuole richiamare in modo molto veloce.

Lascia che ti spieghi con un esempio.

Immagina di avere un team che ha sempre utilizzato TFVC e vuoi migrarlo a Git. Puoi creare degli alias per far usare agli sviluppatore gli stessi comandi che userebbero con TFVC rendendo il passaggio meno traumatizzante. Come? Ti basterà creare un alias chiamato “checkin” che richiamerà in sequenza i comandi Git “commit” e “push” oppure un comando “checkout” che richiamerà il comando “pull”.

Facile vero?

Come vedi Git è così camaleontico da essere potente e complesso solo quando serve e semplice durante la tua routine giornaliera.

Git e Visual Studio

Ti ho parlato di come usare gli alias per rendere Git più familiare a chi proviene da TFVC. E’ molto probabile che gli sviluppatori del tuo team usino già Visual Studio. In questo caso c’è una buona notizia per te: non hai bisogno di crearti alcun alias. Team Explorer è l’estensione di Visual Studio per connettersi ad un sistema di versionamento del codice sorgente. Se hai usato TFVC in passato con Visual Studio lo conosci già.

Team Explorer è perfettamente compatibile con Git e ti permette ti sfruttare tutte le funzionalità dell’uso quotidiano di questo strumento. In più Team Explorer cerca di rendere il più simile possibile l'esperienza d’uso di TFVC e Git aiutando e rendendo la migrazione naturale grazie agli alias.

Come faccio se mi servissero funzionalità di Git non presenti in Team Explorer? Niente paura, puoi sempre passare alla command line per eseguire operazioni più complesse o su cui c'è bisogno di una maggiore granularità dei comandi.

Una volta concluse le operazioni da linea di comando, tutte le modifiche eseguite saranno visibili da Visual Studio e Team Explorer.

Anche in questo caso ti ho mostrato come possiamo usare Git con uno strumento semplice come Team Explorer a cui gli sviluppatori sono abituati e sfruttando le funzionalità avanzate di Git solo nel momento di necessità.

Quando scegliere Team Foundation Version Control o Git?

Abbiamo visto che Git è molto più potente e versatile degli altri strumenti simili, ma nonostante una maggiore complessità di fondo abbiamo gli strumenti per usarlo in maniera similare a come siamo abituati con TFVC. Messa in questi termini viene di chiedersi se ad oggi ha ancora senso continuare a utilizzare TFVC.

In generale no, ma esistono alcuni scenari da valutare con attenzione.

Se abbiamo un progetto di molti anni con cui utilizziamo TFVC, magari basato su un processo di sviluppo consolidato negli anni e che utilizza in largo modo checkin policy customizzate, allora ha senso mantenere TFVC.

In aggiunta, è conveniente mantenere TFVC se abbiamo progetti che modifichiamo molto raramente e su cui facciamo solo qualche piccola operazione di manutenzione senza evolvere.

Il discorso cambia se programmiamo di iniziare un nuovo progetto. In questo caso potrebbe valere la pena sfruttare l'occasione per utilizzare git, magari sfruttando un progetto pilota per farsi le ossa con questo nuovo strumento.

Quando si cambia tecnologia c’è sempre un costo iniziale per gli sviluppatori. Malgrado ti ho mostrato come abbassare questo costo, anche il passaggio a Git non si sottrae a questa regola; Git non introduce soltanto una nuova tecnologia, ma potenzialmente anche una nuova metodologia di sviluppo.

Infatti deve essere tenuto presente che Git, essendo un prodotto più nuovo rispetto agli altri, è anche più adatto a essere utilizzato per pratiche

di sviluppo ed organizzazione dei task del team consolidate in questi ultimi anni. Ne è un esempio il “feature branch”: è una tecnica che prevede che sia creata una nuova branch a partire da quella principale, per ogni nuova feature che si deve sviluppare. Alla fine dello sviluppo della feature, il workflow richiede che lo sviluppatore faccia una “pull request” (PR). Una PR è una richiesta di code review da parte di un elemento del team che, in caso di validazione positiva del codice in termini di design e aderenza alle guideline del team, concluderà il processo di sviluppo della funzionalità con il merge sulla branch principale del progetto integrandosi con il resto delle funzionalità sviluppate e creando una nuova versione pronta per un eventuale test di integrazione.

Ti voglio sottolineare come con TFVC non sia possibile sfruttare il meccanismo delle pull request, diversamente da quanto è possibile fare usando Azure DevOps con Git.

In definitiva, il consiglio è di usare git in tutti i casi al di fuori degli scenari legacy descritti in precedenza. E’ importante considerare la larga diffusione di Git anche e soprattutto in ambiti fuori dal mondo Microsoft. Considera infatti che gli sviluppatori che stanno entrando o sono entrati da poco nel mondo lavorativo, Git è diventato lo strumento standard di fatto di versionamento del codice.

Sai cosa significa?

Se devi reperire nuove risorse per il tuo team, da oggi sarà sempre più facile trovare ed assumere nuovi sviluppatori che conoscono questa tecnologia e sarà sempre più complesso (e costoso) trovarne altrettante per TFVC.

Nei nostri corsi, come nei progetti che sviluppiamo tutti i giorni, utilizziamo Git come strumento base di versionamento e distribuzione del codice. Un progetto solido con costi controllabili ed un team che lavora in modo organizzato e senza stress nasce dalla metodologia di sviluppo e gli strumenti utilizzati a questo scopo sono una scelta cruciale.  Proprio per questo se vuoi sapere come integrare Git con Azure DevOps nei tuoi progetti di tutti i giorni e all’interno del tuo team contattaci subito per partecipare al corso di Gestione Progetti.

Affrettati perché blocchiamo solo pochi giorni ogni anno per aziende selezionate, perché prima di tutto siamo sviluppatori che lavorano su progetti reali.