Qualcuno vorrebbe condividere la propria esperienza nell'utilizzo di TFS per la gestione del ciclo di vita delle applicazioni

Question

stiamo sviluppando applicazioni sanitarie web e mobili white label per i nostri clienti.il nostro prodotto si sta evolvendo rapidamente e supportiamo i clienti esistenti e supporteremo nuovi clienti.

l'attuale flusso di lavoro di sviluppo prevede SVN per il codice sorgente, il monitoraggio dei documenti dei requisiti e Mantis per il monitoraggio dei difetti.

Stiamo prendendo in considerazione la gestione del ciclo di vita delle applicazioni basata su VS TFS 2010 per la nostra organizzazione.speriamo che VS TFS 2010 ci aiuti a semplificare quanto segue

1) Gestione dei requisiti 2) Controllo della versione del codice sorgente 3) Build Automation 4) Gestione dei test

mi chiedevo solo se qualcuno ha esperienza nell'uso di VS TFS 2010 e vorrebbe condividere le proprie esperienze?esistono alternative valide a VS TeamSystem?

Answer 1

Prefazione:Questa è un'opinione personale e non ho alcun legame con Microsoft oltre al fatto che sviluppo con i loro strumenti per la loro piattaforma, anche se in questa risposta mi trovo come un amante di Microsoft.(cosa che sono: adoro lo sviluppo .NET)

Non ho utilizzato TFS 2010, ma HO utilizzato Team Suite 2005 incluso TFS e le versioni di Visual Studio supportate.Non siamo passati al 2008 o al 1020 a causa della straordinaria difficoltà di installazione della versione 2005.Tuttavia, una volta installato...Lo amo.Gli strumenti di gestione del progetto erano intuitivi e funzionavano bene.Configurare le build è stato un gioco da ragazzi e ha fatto tutto ciò che volevo in modo semplice ed efficiente.

Da allora, tuttavia, abbiamo adottato strumenti open source per fare lo stesso tipo di cose.Come ho detto, l'installazione del 2005 è stata un INCUBO e anche se la versione 2010 di Team Foundation Server si installa MOLTO facilmente (l'ho testata io stesso e l'ho dimostrata al povero team che mi ha aiutato con la versione 2005 solo per mostrare loro quanto fosse migliore è), non sono riuscito a convincere il mio team a dargli una seconda possibilità.Hanno scelto di attenersi a strumenti che non necessitavano di essere aggiornati così spesso e che erano più facili da aggiornare quando necessario.

Se fosse solo per me, lo userei.Questa è una di quelle cose in cui le cose funzionano bene e lavorano insieme senza problemi.E la documentazione disponibile (MSDN, video, ecc.) è esaustiva.Dubito che qualsiasi altro set di strumenti sia altrettanto ben documentato.

È semplicemente un peccato che l'esperienza con la versione precedente sia stata così negativa che nessun altro qui darà una scossa alla versione più recente.

Per quanto riguarda le alternative, non è open source, ma Atlante ha un bel set di strumenti.Funzionano bene per Java e ne stiamo utilizzando alcuni nel nostro negozio .NET.Stiamo utilizzando SVN per il controllo del codice sorgente.Questa è l'unica cosa che mi piace di più del nostro nuovo ambiente rispetto al Team System.

Answer 2

Ho iniziato in una nuova società 2 mesi indietro che usi TFS 2010 in esclusiva (per il controllo del codice sorgente e il rilascio / tracking compito), e non sono stato in grado di mettersi a proprio agio con esso. In precedenza, ho usato principalmente SVN per il controllo di origine e sia OnTime (da Axosoft) o Fogbugz (Joel Spolsky) e mi è piaciuto entrambe.

Non so se è il modo in cui stanno usando TFS (ramificazione c'è niente di più bello come lo era nel SVN ... e hanno Backlog prodotto Unità, Sprint Backlog I prodotti che, Bugs, impedimenti, e Dio sa cosa altro per tenere traccia di), ma lo trovo troppo contorto.

Credo che gli strumenti a usi di sviluppo dovrebbero aiutare il dev, non si ottiene nel modo di. Se devo fermare e pensare a come ramo di codice o assegnare un problema, quindi sbagliato di qualcosa con i miei strumenti (o ho solo bisogno di passare più tempo loro apprendimento ... il che non ha senso per me o).