TFS vs alternative open source?[Chiuso]

https://stackoverflow.com/questions/61959

09-06-2019
|

Domanda

Attualmente stiamo configurando un server di controllo del codice sorgente/build/e altro per lo sviluppo .NET e stiamo pensando di utilizzare Team Foundation Server (che costa un sacco di soldi) o di combinare diverse opzioni open source , come SourceForge Enterprise/GForge e Subversion e CruiseControl.net e così via.Qualcuno ha percorso il percorso completo dell'OSS o è TFS solo se vuoi farlo bene e metterti al lavoro presto?

Soluzione

Il mio lavoro attualmente utilizza un processo di creazione prevalentemente OSS con Cruise Control come motore ed è fantastico.Suggerirei che se non sai perché avresti bisogno di TFS, probabilmente non vale il costo.

La cosa che devi tenere a mente con il materiale OSS è che il software è stato utilizzato dal team Java per anni in precedenza, oppure il software è un port di codice Java simile.È robusto ed è adatto allo scopo.

Microsoft non può fornire il codice OSS, motivo per cui deve reimplementare molte cose Open Source.Quindi no, non è necessario e ci sono milioni di progetti spediti in quello stack.Il rovescio della medaglia è che ci sono anche molte funzionalità interessanti che ottieni con TFS che non otterrai (facilmente) con lo stack OSS, come l'integrazione con il tuo software di monitoraggio di bug/funzionalità.

Altri suggerimenti

Ho sempre seguito la strada dell'OSS e non ho mai avuto problemi.Raccomanderei vivamente TeamCity anche per la tua soluzione CI.Esiste una licenza gratuita e penso che faccia saltare CC.NET fuori dall'acqua per facilità di configurazione e feedback.

Sono un utente quotidiano di TFS da circa 1,5 anni ormai.

Il controllo del codice sorgente è stabile
Non è facile lavorare disconnessi.L'estrazione dei file va al server.
L'unione automatica funziona benissimo, tranne che a volte corrompe il file sorgente (problema di codifica).
TFS ha una sensazione lenta!?Soprattutto il responsabile del test.Codice gestito?
Ci sono vari bug stupidi nella parte di test, niente di critico.
L'avvio delle esecuzioni di test richiede troppo tempo (in sospeso).
Di tanto in tanto ricevo deadlock SQL!?
Il monitoraggio dei problemi fa schifo, imho.Sei costretto a lavorare nelle lente finestre di dialogo integrate, il web è solo di visualizzazione.Consiglio di confrontarlo con altri sistemi di tracciamento dei problemi, come JIRA
Le build funzionano bene.

Se stai utilizzando TFS assicurati di installare VSTS2008SP1.La stragrande maggioranza delle persone che ho visto pubblicare reclami utilizza la versione 2005.Il 2005 è la classica sindrome "Microsoft 1.0".C'erano MOLTI problemi che sono stati risolti dalle due "versioni" successive.

Il Service Pack per il 2008 non è solo una correzione di bug, ma aggiunge molte nuove funzionalità.

Per quanto riguarda la scelta rispetto all'OSS, ci sono molte discussioni (qui e altrove).Non è un prodotto economico, ma è la scelta migliore per molti scenari (e la peggiore per altri).

Abbiamo esaminato TFS, ma alla fine abbiamo optato per Subversion + Trac + VisualSVN.Non facciamo CI in questo momento, ma penso che il Cruisecontrol sarebbe quello che useremmo.

Ho iniziato a utilizzare Trac con numerosi progetti open source ed è fantastico.In realtà è solo una parte di ciò che fa TFS, quindi dovrai prendere una decisione lì: se usi tutto, TFS probabilmente fa un lavoro migliore nel collegare tutto insieme.Trac è un wiki/bug tracker/browser sorgente.Tutto è collegato: quando digiti il nome di una WikiPage o dici "Correggi bug n. 1234" in un messaggio di commit, ogni volta che vedi quel messaggio in Trac i collegamenti vanno nei posti giusti.È uno strumento che ti aiuta a fare il tuo lavoro e che, in generale, rimane fuori mano.

VisualSVN è un ottimo ponte tra TortoiseSVN (un client Subversion) e VisualStudio e migliora notevolmente la produttività.Hanno una prova gratuita e dopo non è molto costosa ($50/utente), ma ne vale la pena.

Un possibile svantaggio di Trac è che in un mondo Windows è una seccatura lavorare su IIS.Ho installato Trac molte volte, ma mi sono subito sentito frustrato nel tentativo di farlo funzionare correttamente.Alla fine ho installato Apache su un IP diverso (potrei anche utilizzare una porta diversa) e quindi è stato tutto perfetto.

Ad eccezione di una persona del mio team (che aveva un po' di esperienza), nessuno aveva mai usato la sovversione prima.Una coppia aveva usato VSS, e questo è tutto.Tutti erano piuttosto scettici, ma direi che nel giro di pochi giorni si convertirono tutti.Dopo aver imparato completamente Trac e essersi abituati a tutto (qualche giorno in più), tutti sono totalmente convinti e lo adorano.

La nostra azienda utilizza la combinazione CruiseControl/SVN/nAnt/JIRA con grande successo.

Il problema con TFS è che ne vale la pena solo per le aziende più grandi.Sarà terribilmente costoso per le piccole aziende con 30 o meno sviluppatori, che trarrebbero già grandi benefici dalla combinazione open source di cui sopra.

Subversion + Cruisecontol.Net è una buona alternativa.SVN è ricco di funzionalità, stabile e flessibile.

Il vero vantaggio dell'utilizzo di TFS rispetto a un set separato di strumenti del sistema operativo è l'integrazione dei vari flussi di informazioni disponibili.

* Crea un requisito e inseriscilo in TFS
* Creare una serie di attività collegandole ai requisiti e assegnarle ai vari sviluppatori
* Ogni sviluppatore lavora sulla propria attività e check-in, assegnando l'attività al changeset archiviato
* Arriva una correzione del bug, anche in questo caso il set di modifiche sarà coordinato con la richiesta di correzione del bug ed è anche possibile mappare la correzione del bug sul requisito originale

Una volta fatto questo tutte le informazioni possono essere utilizzate per tenere traccia del progetto e fare valutazioni sul lavoro, come ad esempio quante modifiche ha causato una correzione di bug, quali sono i requisiti che hanno generato più bug o richieste di modifica e così via.

Tutte queste informazioni sono molto utili nelle organizzazioni di medie e grandi dimensioni e, da quello che vedo ora, non è possibile (o molto difficile) monitorare l'integrazione di diversi strumenti del sistema operativo.

Lo stack TFS è molto più del controllo del codice sorgente e di una configurazione di compilazione CI/notturna.Pensa alla gestione dei progetti, alle segnalazioni di bug e tutto si aggiunge a qualcosa di più che solo CruiseControl, SVN e NAnt.Anche solo i rapporti potrebbero valere l’investimento.E ricorda anche che se sei un abbonato MSDN/ISV gold partner/ecc.potresti riceverne una parte gratuitamente...

Ho iniziato solo di recente a lavorare quotidianamente con TFS e, provenendo da uno stack precedentemente open source, lo trovo piuttosto carente.

Sebbene l'integrazione di tutti i bug e il monitoraggio delle attività sia una funzionalità davvero eccezionale, gli aspetti negativi la appesantiscono.

Personalmente utilizzo il seguente stack che mi offre tutto ciò che dobbiamo fare, dall'integrazione continua alle distribuzioni automatizzate su scala aziendale a una frazione del costo:

Ho visto entrambi in azione (anche se sono uno sviluppatore Java).Il vantaggio di un approccio pick and mix è che puoi scegliere le parti migliori per tutto (ad es.Darei un'occhiata a Hudson per CI: è eccellente per Java, funziona anche per .Net e lo ha fatto carichi di plugin ed è davvero semplice da usare).Lo svantaggio è che devi fare tutta l'integrazione da solo.Tuttavia, questo sta diventando un quantità più facile nel mondo Java.Inoltre, non lasciare che la gente ti dica che un prodotto supportato è migliore.Su molti prodotti OSS in questo spazio la qualità è eccellente e ottieni Meglio supporto dalla comunità piuttosto che aspettare una risposta dal contratto di supporto del tuo fornitore (IBM, sto guardando te)

Spero che questo ti aiuti.

Sono assolutamente d'accordo con il punto che vale la pena utilizzare TFS solo se sai esattamente a cosa ti serve.I componenti aggiuntivi basati su OSS, economici o gratuiti come Visual SVN e TestDriven.Net sono così validi che l'integrazione con VS è già perfetta.

Ho pensato di aggiungere una nuova prospettiva che può essere presa con le pinze perché non l'ho ancora provata, ma ho intenzione di usarla Morso per CI in un progetto imminente.Funziona su Trac+SVN, entrambi ottimi strumenti che ho utilizzato con successo per molti progetti.

Abbiamo creato gradualmente uno stack di sviluppo qui, attualmente stiamo utilizzando:

Sovversione
Regolazione automatica della velocità
RedMine (integra il tracciamento dei bug con il controllo del codice sorgente e include wiki, gestione dei progetti di base, ecc.).

Penso che valga la pena utilizzare TFS per tutte le funzionalità extra menzionate nei post precedenti.Tuttavia, la funzionalità di creazione continua è seriamente carente, quindi abbiamo aumentato quella parte utilizzando CruiseControl.NET, il che è fantastico.L’unico motivo per cui sceglieremmo contro TFS se lo facessimo adesso è che ci stiamo muovendo verso lo sviluppo multipiattaforma dei nostri prodotti.Quindi, se ci hai pensato, pensa all'OSS.Subversion/Trac sarebbe la mia combinazione preferita in questo modo con CruiseCOntrol.NET che rimane la spina dorsale.CC.NET utilizzando mono funziona bene su Linux e Mac.

TFS2010 ha un TFS Basic, che non costa nulla (oltre all'abbonamento MSDN/licenza Visual Studio).È limitato a 1 per licenza VS, ma sono necessarie solo licenze aggiuntive per gli utenti non VS

L'automazione dell'interfaccia utente in VS2010 da sola rende TFS un vincitore nel mettere insieme soluzioni open source

Vale la pena ricordare che la migliore alternativa a un'ampia gamma di funzionalità TFS non sono necessariamente OSS, ma commerciali a basso budget, come NDipende per la qualità del codice e l'esplorazione dell'architettura, NCopertina per la copertura del codice, TestDriven.NET per i test nidificati nell'IDE ...

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow