Tag Archives: Git

Nuovo sprint in VSO

Sono state messe online le modifiche del nuovo sprint per Visual Studio Online, e questa volta le novità sono veramente interessanti e tante.

Per prima cosa è ora live la nuova infrastruttura di build, di cui avete avuto una preview con TFS 2015 RC. La build è stata completamente riscritta, e le novità sono veramente molte. Avevo già iniziato a parlare della nuova infrastruttura di build in un vecchio post, TFS2015 build vNext, ed ora che la preview è pubblica in VSO seguiranno altri post sull’argomento.

Abbiamo inoltre una nuova funzionalità per fare opt-in nel Portfolio Management, è ora infatti possibile decidere se utilizzare o meno il livello Features, ed è stato anche aggiunto il livello Epics. Nei template sono stati aggiunti nuovi campi per un migliore supporto al metodo di sviluppo SAFe (Scaled Agile Framework).

Choosing portfolio backlog levels

Continuano infine le migliore alla Kanban Board. Con questo sprint potete editare in place, direttamente nella card, ogni campo che avete visualizzato; questo vi permette di gestire in maniera molto più veloce le varie card.

Sono state aggiunte poi le Branch Policies su Git, ovvero la possibilità di assegnare una build alle pull requests. In questo modo ogni qualvolta viene fatta una pull request di una branch, viene verificata la build e se quest’ultima fallisce non viene data la possibilità di fare la merge dalla interfaccia utente. Inoltre è possibile specificare altre regole, come ad esempio un numero minimo di revisori minimo affinché la pull request possa essere accettata. Sempre sul fronte git è ora possibile accedere ai repository direttamente utilizzando oAuth.

Gian Maria

Comments Off on Nuovo sprint in VSO  

Amending in Git

Nell’ultimo update di Visual Studio (Update 2 ora in RC) il supporto a Git continua ad evolversi, portando direttamente nella UI altre operazioni che erano appannaggio della Command Line. Debbo dire che una volta imparato Git la Command Line rimane sempre la vostra piu cara amica, perchè vi darà sempre pieno accesso a tutte le […]

Comments Off on Amending in Git  

Supporto Git in VS e commandline

Nel precedente post Antonio ha parlato del concetto di Spike e del possibile utilizzo in TFS dello Shelveset come strumento di supporto per quanto riguarda il Source Control nativo di TFS (abbreviato in TFVC). Per quanto riguarda Git, il concetto più vicino che si ha ad uno Shelveset è il comando Stash. Questo comando è […]

Comments Off on Supporto Git in VS e commandline  

Spike Solutions in Team Foundation Server 2013

Spesso nello sviluppo di un software è necessario effettuare l’upgrade di componenti o framework presenti nella propria soluzione, fase che è poi seguita da compilazione e testing dell’applicativo per identificare eventuali problemi di natura tecnica o funzionale. Naturalmente queste operazioni vengono eseguite sulla macchina locale, prima di condividerle sulla main con gli altri sviluppatori.

image

[fonte: http://www.extremeprogramming.org/rules/spike.html]

Poniamo ad esempio, che vogliamo aggiornare la versione di Entity Framework nel nostro progetto, ma vogliamo essere sicuri di non andare incontro a qualche breaking change. Se l’aggiornamento ha esiti positivi, possiamo promuovere il codice alla nostra linea principale. Nell’eventualità che queste modifiche non vadano a buon fine, in genere il codice viene eliminato.

Questa operazione viene definita come Spike, termine coniato in Extreme Programming.

Lo spike in genere si usa nei seguenti casi:

  • Codice per testare nuovi framework o tecnologie;
  • Codice per isolare e testare bugs che si sono verificati in un framework o una libreria;
  • Codice one-time shot, come nei casi di importazione massiva di dati da effettuare un’unica volta;

Poiché l’intero processo si basa sul testare o ritestare il proprio applicativo,gli spike sposano benissimo la metodologia Test Driven Development, perché in questo modo, dopo aver aggiornato il proprio progetto o è possibile creare un pò di unit test per le user story, oppure rieseguire l’insieme di unit test già presenti per verificare eventuali problematiche.

In Team Foundation Server non esiste alcuna funzionalità che prende il nome di spike, anche se però esiste qualcosa che si avvicina al concetto di base: la Shelveset.

La Shelveset è un’area che può essere utilizzata per diversi motivi:

  • Interruzione momentanea del lavoro;
  • Condivisione del proprio work in progress con un altro membro del team;
  • Code review;
  • Build e automazione prima del check-in;
  • Backup.

Per creare una Shelveset in Team Foundation Server basta selezionare la voce Shelve all’interno della sezione Pending Changes nel Team Explorer. E’ sufficiente dare un nome ed un eventuale commento.

image

Una importante scelta che occorre fare in questa fase è selezionare o no la voce “Preserve Pending Changes Locally”. Tramite questa opzione possiamo scegliere se lasciare le modifiche nel nostro workspace (selezionata) oppure rimuoverle se ad esempio dobbiamo lavorare sugli stessi file a cui abbiamo apportato delle modifiche.

Se abbiamo necessità di condividere queste modifiche con un altro utente, possiamo utilizzare nel menù Actions della stessa sezione del Team Explorer la voce “Find Shelveset”. Da qui possiamo filtrare tramite il nome utente e cercare la Shelveset di nostro interesse.

image

Poiché in TFS 2013 è stato aggiunto il supporto a Git, pare opportuna la domanda su come gestire le spike con questo DVCS. In sostanza, se usiamo Git come repository, purtroppo non abbiamo la voce Shelve, ma il meccanismo che possiamo usare per gli spike sono i branches. Quindi quello che facciamo nel momento in cui abbiamo il nostro spike, è creare un nuovo branch in fase di commit:

image

Dopo aver pubblicato il branch, abbiamo la possibilità di continuare a lavorare e di dare la possibilità anche ai nostri colleghi di poter lavorare direttamente dal branch.

Più un generale, l’uso dei branches può essere applicato anche se si usa il TFVC. Questo facilità sicuramente la possibilità di creare e condividere ai colleghi il proprio codice che si sta testando, per poi promuoverlo alla linea principale attraverso il meccanismo di merging (occhio come sempre ai permessi che hanno gli utenti sul branching e merging). In genere si può adottare una organizzazione delle cartelle di questo tipo:

  • MioProgetto
    • dev (folder)
      • feature1 (branch)
      • feature2 (branch)
      • feature3 (branch)
    • main (branch)
    • blackOps (folder)
      • EF6 (branch)
      • NHibernate (branch)
      • ELibLogging (branch)
    • releases (folder)
      • V1 (branch)
      • V1 HotFix (branch)
      • V1 SP1 (branch)

In questo caso ho usato come nome della cartella BlackOps, ma qualsiasi altro nome come Spike va benissimo.

 

Enjoy it! Smile

Git non è GitHub

Il titolo sembra veramente stupido, però in realtà non lo è. Da quando Tfs supporta nativamente Git come Source Control, ovvero all’incirca da Gennaio 2013 per Visual Studio Online e dalla versione 2013 per le installazioni on-premise, si è generata un po di confusione. Quello che accade spesso è questo, alla fatidica domanda: che source […]

Comments Off on Git non è GitHub  

Il supporto a Git per VS2012 è oramai RTM

Come molti di voi sapranno, Visual Studio 2013 fornisce supporto nativo a Git, mentre per la versione precedente, Visual Studio 2012 è necessario installare un apposito plugin. Oggi Brian Harry ha annunciato che è finalmente disponibile la versione RTM e definitiva di questo plugin che potete scaricare direttamente dalla Visual Studio Gallery a questo indirizzo: […]

Comments Off on Il supporto a Git per VS2012 è oramai RTM  

Repository Git multipli su uno stesso Team Project

Questa funzionalità è presente da molto tempo in TF Service (e naturalmente è presente in TFS 2013) e consiste nel poter creare più repository Git per uno stesso Team Project. L’aspetto interessante è che è possibile dare credenziali differenti ai differenti repository, permettendo quindi libertà di organizzazione del codice Se avete installato la versione RC […]

Comments Off on Repository Git multipli su uno stesso Team Project  

Nuovo deploy per TF Service

In pieno spirito Scrum, il Team di TFS ha rilasciato il risultato del nuovo sprint su TF Service, e potete leggere tutti i dettagli nelle news. Le novità più interessanti riguardano Git, soprattutto per supportare quello che viene chiamato Enterprise Grade Git, ovvero dotare Git di tutte le funzionalità che sono necessarie per essere adottato […]

1  

Git per Visual Studio 2013 in 9 punti

L’introduzione al supporto di Git in Visual Studio 2012 ha suscitato grande interesse tra gli sviluppatori.

Il principale intento di Microsoft, come annunciato più volte da Brian Harry, è quello di avere in TFS sia il supporto ad un centralized version control system che ad un distributed version control system. Per chi non conosce bene le differenze fra queste due tipologie di VCS, consiglio vivamente la lettura dell’articolo “Differenze tra source control centralizzato e distribuito” di Gian Maria Ricci che trovate nella sezione articoli su getlatestversion.it.

Sebbene Git sia un prodotto non Microsoft, Brian Harry ha evidenziato il massimo sforzo da parte del suo team per dare il 100% di compatibilità di con questo VCS (nelle sue versioni stabili) e con i relativi client. Di sicuro rappresenta una grande sfida per il team di TFS, che si concentra sostanzialmente nell’integrare Git all’interno della piattaforma per l’ALM di casa Microsoft.

Con l’uscita di Visual Studio 2013, il supporto a Git è stato migliorato e ampliato.

Ecco i 9 aspetti positivi che definiscono l’integrazione di Git in TFS e che lo stesso Harry ha citato sul suo blog:

  1. Installazione: nessuna installazione richiesta, già integrato in Visual Studio 2013 (per Visual Studio 2012 occorre scaricare questo plugin);
  2. Supporto: pieno supporto per Git. Nel momento in cui vengono riscontrati problemi è possibile contattare l’assistenza di Microsoft per essere aiutati nella risoluzione. Il supporto include anche aggiornamenti e hot fixes.
  3. Alta disponibilità: pieno supporto a load balacing e clustering, geo-replication, online-backup e online-restore. Il tutto per avere uno strumento sempre attivo e funzionante al 100%.
  4. Scalabilità: sia sull’application tier che sullo storage tier.
  5. Manutenibilità: totalmente integrato nel pannello di amministrazione di TFS fornendo la gestione degli account, monitoraggio, backup, restore…
  6. Autenticazione integrata: piena integrazione con Windows Active Directory.
  7. Gestione dei permessi: controllo dei permessi assegnati agli utenti sui repository (che sarà reso ancora più granulare nelle prossime release)
  8. ALM Integration: piena integrazione con tutto ciò che TFS mette a disposizione per la gestione del ciclo di vita del software (work item, build, reportistica)
  9. Localizzazione: localizzato nella stessa lingua del proprio TFS.

Non vi resta altro che provarlo! Sorriso

 

Enjoy it!

Alcune novità del TFS 2013, supporto Git

Una delle più interessanti novità del TFS 2013 è il supporto a Git, già introdotto in TF Service a gennaio e disponibile ora anche per la versione on-premise. Tutto quello che si deve fare è semplicemente scegliere Git come Version Control System durante la creazione del vostro nuovo Team Project ed il gioco è fatto, […]

1