Come valutare il passaggio a Team Foundation Server

Il mio team di sviluppo attualmente utilizza il seguente software nel nostro flusso di lavoro:

• JIRA
• Bamboo (integrazione continua atlassiana)
• Greenhopper (gestione agile del progetto Atlassian)
• Confluenza
• Git, ospitato su BitBucket
• Visual Studio 2012

Come puoi vedere, siamo abbastanza investiti nell'ecosistema atlantico. Stiamo prendendo in considerazione il passaggio a TFS in modo da poter ottenere le bellezze delle integrazioni avanzate di Visual Studio come revisioni del codice e, soprattutto, Microsoft Test Manager.

La mia precedente esperienza con TFS è stata con il 2005 o il 2008 (non ricordo) e ne ho brutti ricordi, anche se non tanto quanto il mio tempo trascorso con ClearCase.

Quali criteri dovremmo considerare per valutare correttamente il nostro passaggio a TFS?

Il piccolo sondaggio di Martin Fowler dice molto sullo stato della TFS negli anni precedenti. "pericoloso" ha ragione. (Penso che questo si riferisca al modo in cui non riconosce le modifiche apportate al di fuori di VS, quindi puoi creare un progetto WCF, quindi utilizzare lo strumento svcutil esterno per creare il tuo client, quindi controllare tutte le modifiche in .. ma TFS lo farà ignora felicemente le modifiche del tuo client perché non sono state apportate all'interno di VS).

Devi contare il costo: la versione richiesta di VS per ottenere le chicche - le revisioni del codice, ad esempio, richiedono un'edizione Premium che è significativamente più costosa se ottieni VS tramite MSDN. Inoltre, l'accesso al sistema per utenti non VS va bene, ma se desiderano invece l'accesso completo alla visualizzazione Web ridotta, dovrai sborsare CAL per loro. Il costo complessivo di TFS può essere abbastanza. Anche il recente rapporto di Forrester(commissionato da Microsoft, quindi devi leggere un po 'tra le righe) afferma che TFS richiede un significativo supporto amministrativo - 2 consulenti e 6 amministratori (che hanno trascorso il 25% del loro tempo) erano tenuti a supportare TFS per il loro caso di studio di 122 utenti (funziona con 4.5 amministratori su quei 122 utenti ... questo è molto rispetto a me solo a configurare e mantenere una soluzione SVN completa mentre faccio anche il mio lavoro quotidiano). TFS può fare molti sforzi per continuare a lavorare come le persone si aspettano.

Nella mia esperienza con TFS2012 (dimentica le versioni precedenti perché sono una schifezza), è che è un'amministrazione di sistema molto complicata, specialmente se esci dall'installazione predefinita. Ad esempio, se usi MSBuild per creare tutto, stai bene. Ma se hai, diciamo, un carico di vecchie proposte .vdproj che non sono più supportate da MSBuild, devi modificare l'enorme script di compilazione xaml per farlo costruire questi progetti. Dopo diversi giorni di lavoro su questo, il meglio che potevo fare era ricostruire la soluzione passandola a devenv, e anche allora, ottenere i risultati della compilazione e nel suo sommario era impossibile. Risultati simili sono stati ottenuti da altri team che hanno utilizzato NUnit per i loro test: se si utilizza MSTest integrato, allora funziona. Altrimenti, sei praticamente impagliato.

Come utente, trovo che l'integrazione sia più una seccatura. Preferisco TortoiseSVN e faccio quasi tutto il mio lavoro SCM tramite quello (in quanto è uno strumento fantastico). Con TFS, si ottiene una nuova schermata all'interno di VS per ogni operazione. Quindi hai una nuova scheda nel tuo ambiente per il team explorer e un'altra per le build, e un'altra per ogni riepilogo build che vuoi vedere (e se vuoi vedere i dettagli di una build, un errore, ad esempio, hai fare clic su troppi collegamenti). Ho scoperto che il numero di documenti che avevo aperto durante l'utilizzo di TFS era superiore ai file di origine!

Lo stesso vale per i check-in, è necessario eseguire le modifiche facendo clic su diverse schede nel riquadro Modifiche in sospeso in VS per assegnare un oggetto di lavoro e commentare ai check-in. È una cosa piccola, ma l'ho trovato fastidioso perché ero abituato a strumenti più snelli.

L'estensione del sistema di compilazione è stata un'altra area che ho trovato carente. Aggiungere nuove funzionalità nella build è difficile a causa della configurazione di xaml e ottenere i risultati di tali funzionalità nelle schermate della build è molto difficile o impossibile. Quindi, se ti piace aggiungere cose come la complessità del codice o l'analisi statica, o anche i test automatizzati tramite, diciamo selenio o distribuzioni ... dimenticalo. A meno che non si utilizzino gli strumenti Microsoft per questi aspetti (ad es. Fxcop).

L'aggiornamento del flusso di lavoro è stato un altro inconveniente - anche se i powertoys hanno aiutato moltissimo, era ancora imbarazzante ottenere il flusso di lavoro giusto e non è ancora possibile configurare la mischia con le informazioni che si vogliono davvero vedere - di nuovo, si ottengono le impostazioni predefinite o niente .

Anche la fusione è stata dolorosa, penso che ci sia un ottimo motivo per cui MS ha adottato git per TFS (nota che funziona solo con progetti TFS nuovi di zecca, non puoi convertire da TFS a backend git).

Quindi, tutto sommato, non è poi così male perché funziona, ma ho trovato molti altri strumenti molto migliori. Lo svantaggio di questi strumenti è che non sono completamente integrati, ma IMHO questo è un punto di forza in quanto puoi scegliere i pezzi migliori che desideri. Con TFS ottieni praticamente ciò che qualcun altro vuole che tu abbia. Se decidi che il sistema di bug in TFS è scarso (e penso che lo farai), avrai difficoltà a passare a un altro.

La TFS dovrebbe essere presa in considerazione insieme ad altri strumenti grandi e grassi per l'intero ciclo di vita. La maggior parte degli sviluppatori odia le cose che non amano le restrizioni che questi strumenti finiscono per imporre loro.

Vorrei provarlo, scaricare le prove di 30 giorni e installarlo. Durante la valutazione ricordati di cambiare un po 'qua e là, non limitarti a usarlo per un check-in del codice sorgente, esegui il check-in con un elemento di lavoro richiesto e ottieni rapporti basati su quell'elemento di lavoro. Prova ad assegnare un check-in a più elementi di lavoro e prova a combinare elementi di lavoro come correlati. Prova a incorporare qualcosa di diverso nel sistema di compilazione, scopri come ottenere un rapporto sui progressi giornalieri dai servizi di reporting, collega un documento a un requisito del flusso di lavoro e traccialo attraverso il triage di bug fino alla codifica per costruire per rielaborare e quindi rilasciare. Ramifica e unisci molto. Se non riesci a fare facilmente tutte queste cose, allora potresti anche restare fedele a Git. Non ha molto senso utilizzare TFS se non si sfrutta la maggior parte delle sue funzionalità ALM.

Mi sono trasferito da una società con uno stack in gran parte atlantico (e Mercurial) a una società con uno stack TFS pesante. Trovo due irritazioni.

Il primo è il controllo del codice sorgente .

Quando ti sei abituato al DVCS, tornare a un CVCS è doloroso. TFS è particolarmente doloroso perché, nonostante tutta l'integrazione funzioni, insiste per essere sempre connesso al server.

Tuttavia, per fortuna, Microsoft ha recentemente consentito l'integrazione del controllo della versione Git nel resto dello stack TFS. Quindi non devi rinunciare a Git, e ti consiglio di non farlo, dato che lo sanno già tutti.

Non sono ancora sicuro di come lo strumento di revisione del codice funzioni contro Git, dato che sembra fare molto affidamento sugli scaffali (un po 'come gli stash, ma non così potente). Ma fare affidamento sugli scaffali per la revisione del codice è di per sé doloroso perché scoraggia impegni regolari.

L'altra irritazione è il motivo per cui molte persone non prenderanno in considerazione l'idea di abbandonare TFS: l'integrazione di Visual Studio .

Devo ancora capire il ragionamento cognitivo dietro questo, ma, nella mia esperienza (e tenendo conto del fatto che questo è generalizzante), le persone che sono abituate a TFS amano l'integrazione. A loro non piace uscire dall'IDE per nulla.

Io, d'altra parte, non mi sono riscaldato dopo un anno. Lo trovo ingombrante e difficile da navigare, rispetto ad avere il mio server di build in una scheda del browser, i miei biglietti in un'altra scheda del browser e così via. (Modifica: come osserva Andrei, c'è un'interfaccia web, ma è anche inspiegabilmente goffa, quando sei abituato alle versioni più recenti di Jira e Jenkins. Ma comunque, almeno funziona con browser diversi da IE ora. Quindi è qualcosa.)

Non guardo mai le build a meno che non stia provando a farne una, e poi trovo difficile scoprire se qualcun altro ne sta già facendo una. Non vedo i cambiamenti delle altre persone a meno che non mi venga chiesto di rivedere.

Ma il tuo chilometraggio può variare. Come ho già detto, alcune persone sembrano trovarlo indispensabile. Non posso fare a meno di notare che in genere sono le persone che non l'hanno mai fatto in un altro modo.

Inoltre, non dimenticare che si tratta di 2 aspetti negativi, uno dei quali può essere personale, in un'infrastruttura piuttosto grande. Gran parte della mia esperienza è buona e TFS non è così male come alcune persone ti faranno credere. E la maggior parte delle cose che trovi che ti manca possono probabilmente essere accese (è molto configurabile); dato che stai spostando un'intera squadra, piuttosto che una persona, potresti trovare meno resistenza.

Ho avuto un'esperienza molto positiva nell'uso di TFS 2012. È abbastanza facile configurare e far funzionare il tuo server TFS, l'automazione della build CI è molto semplice e diretta (e la build del check-in Gated è semplicemente fantastica. Non siamo riusciti a ottenere la stessa funzionalità con Team City). L'interazione di squadra è anche molto trasparente e diretta. È possibile associare facilmente i check-in a elementi di lavoro TFS, gestire un backlog, tenere traccia dei difetti, eseguire visualizzazioni di codice e così via. C'è persino un messenger compilato in =)

Tuttavia, tieni presente che se ti sei abituato al flusso di lavoro di JIRA, impostare il flusso di lavoro TFS potrebbe essere un compito difficile. Suggerirei di adottare uno dei flussi di lavoro TFS predefiniti. Inoltre dovrai mantenere Confluence come base di conoscenza o passare a SharePoint in quanto non esiste un wiki integrato in TFS.

TFS è molto più economico se si dispone di un abbonamento MSDN (credo che la maggior parte delle aziende di sviluppatori che lavorano con stack di tecnologia MS ce l'hanno) in quel caso si dispone di TFS gratuitamente.

Penso che non vi sia motivo di continuare a utilizzare gli strumenti di parti secondarie se tutti gli sviluppatori lavorano con Visual Studio. TFS offre un sistema ALM integrato, robusto ma facile da usare. Sarò lieto di rispondere alle tue domande se ne hai.

La gente dovrebbe sapere, TFS non è solo VCS, è ALM .

Sembra che molte persone vogliano solo un VCS ma optare per TFS è sbagliato.
Per CVCS, preferisco ancora SVN.
Per assolo o open source, scegli GIT.

Ma TFS2012 non è male, è facile capire su merge / fork quindi SVN.
E il servizio Team Foundation è gratuito per 5 repo utente / illimitato e privato.

Anche il client è gratuito, TFS Explorer si basa su VS2010 ed è gratuito.
Per Eclipse, ha il plugin Eclipse - TFS ovunque.

Non vedo alcun problema di costo su questo.
TFS express (gratuito) può funzionare con SQL Server Express (anche gratuito).