Team Foundation Build o TeamCity?

Question

Siamo un'azienda prevalentemente MS che lavora allo sviluppo di .NET LOB.Utilizziamo anche MS Dynamics per la nostra app CRM...tutti gli sviluppatori utilizzano attualmente VS/SQL Server 2008.Usiamo anche VSS, ma tutti lo odiano al lavoro e sta rapidamente scomparendo.

Stiamo avviando la nostra iniziativa per l'implementazione del TDD in tutto il team (~ dozzina di persone).Ho ottenuto la configurazione di TeamCity e le mie prime build automatizzate vengono eseguite con successo utilizzando il builder sln del 2008 e anche utilizzando SVN configurato da un collega che sta eseguendo l'analisi del controllo del codice sorgente.Durante la dimostrazione al management, penso che abbiano iniziato a credere nel mio olio di serpente e hanno lanciato il suggerimento di esaminare TFS.

Ciò ha gettato una svolta in ciò che avevo pianificato per la nostra architettura TDD;In senso positivo, però, perché ho sempre pensato che TFS fosse semplicemente troppo costoso e non ne valesse la pena per il nostro team (e ho visto lo stesso in altri negozi in cui ho lavorato / di cui conosco).Ho la sensazione che la SM sia indietro di anni nell'area TDD/CI e che i prodotti di terze parti fossero probabilmente molto migliori e più maturi...Devo ancora fare molte ricerche, ma ho pensato di venire qui per vedere se qualcuno ha effettivamente utilizzato entrambi i sistemi.

Mi rendo conto che TFS comprende molto di più di un semplice server di compilazione...ma non volevo rendere la questione troppo ampia, almeno di proposito. Quali sono i pro/contro pratici dell'utilizzo di TFS/TFB invece di TeamCity, ad es.quali benefici perderemmo/guadagneremmo?Qualcuno qui ha effettivamente utilizzato entrambi i sistemi (TFS per TDD/CI e TeamCity/SVN) e può parlare dal punto di vista pratico?

Ho effettuato alcune ricerche su questo argomento e un post che ho trovato qui su SO menzionava che lo svantaggio di TFB era che supportava solo MSBuild.Avevo intenzione di utilizzare FinalBuilder con TeamCity;e sembra che supporti anche TFS...

Grazie per qualsiasi consiglio

MODIFICARE:Qualcuno ha utilizzato TFS come server Build/CI e può raccontare storie di successo/fallimento?

Answer 1

Siamo un piccolo negozio di sviluppo, e abbiamo deciso che il Team Foundation Server porta troppo in alto per noi. Abbiamo usato per scrivere script MSBuild personalizzati per eseguire da linea di comando, ma dopo abbiamo scoperto TeamCity, abbiamo spostato il nostro intero processo di generazione verso di esso.

Abbiamo scoperto TeamCity per essere facile da usare e configurare, e JetBrains fornisce un eccellente supporto e documentazione. Sono anche su un ciclo di rilascio e aggiornamento molto più veloce di Microsoft.

Il loro sostegno per il controllo del codice sorgente SVN è eccellente, e ci piace il fatto che essi supportano sia MSTest e NUnit per unit testing.

C'è piaciuto anche il fatto che l'edizione TeamCity professionale era libero, così abbiamo potuto valutare per vedere se ha funzionato per noi. Non abbiamo colpito il numero di configurazioni di progetto (20), che ci richiederebbe di effettuare l'aggiornamento alla versione Enterprise.

Answer 2

Questa domanda ha molte buone risposte su TeamCity.Non è paragonabile a TFS ma potrebbe farti luce su TeamCity.

Li ho usati entrambi e ho avuto successo con entrambi, ma TeamCity è stato molto più semplice.È stato un gioco da ragazzi impostare e configurare TeamCity.TFS non lo era.TeamCity è solido come una roccia, è facile da mantenere e funziona semplicemente.Gli sviluppatori di JetBrains hanno fatto un ottimo lavoro rispondendo alla community.Ottengono un rilascio ogni 6-8 mesi che aggiunge un valore reale.TFS ha un ciclo di 2 anni o più.

TeamCity ti offre più scelta su come costruisci e quale controllo del codice sorgente usi.Non è tutto in uno, ma a volte è una buona cosa.Ha anche un buon set di punti di estensione.Siamo anche molto soddisfatti del modello di agente che ha.

Ho eseguito 3 aggiornamenti assolutamente indolori in TeamCity.L'unico aggiornamento di TFS che abbiamo eseguito ha interrotto la compilazione e il controllo del codice sorgente per 3 giorni.Sono l'amministratore di TeamCity nel nostro progetto e ci vogliono un paio d'ore al mese.TFS impiegava un paio di giorni a settimana.

TeamCity + SVN + VisualSVN è stato l'ambiente più fluido in cui abbia mai lavorato.TFS era generalmente regolare giorno per giorno, ma solo se c'era qualcuno che lo faceva funzionare.

Spero possa aiutare

Answer 3

I benefici di TFS sono un unico ambiente integrato che è supportato da Microsoft. Io personalmente non mi piace TFS per il controllo del codice sorgente e hanno avuto una serie di problemi con esso. E 'goffo, ma aveva il vantaggio di avere VS integrazione (che è disponibile in VisualSVN anche, ma non è così robusta).

Personalmente, penso che sarebbe molto meglio utilizzare SVN / TeamCity. E 'solo più facile da lavorare e si comporta più come ci si aspetterebbe. Come con la maggior parte del software open source, entrambi sono in costante evoluzione e avrà sempre la funzione di ultima e più grande prima di Microsoft. L'integrazione tra il 2 è veramente buono e non ho trovato difetti fatali nel sistema. Mi spingo costantemente di seguire questa strada nella mia società attuale (usiamo TFS), come credo che sia un flusso di lavoro molto meglio. Come ulteriore vantaggio, è molto più conveniente che andare il percorso TFS.

Ho anche usato FinalBuilder con TFS - la mia domanda c'è quello che stai veramente comprando con FinalBuilder che non si può fare con NANT / MSBuild? La risposta al mio negozio è, purtroppo, molto poco IMO.

Answer 4

Prima di tutto, vedi questo post:

SVN vs Team Foundation Server

Per quanto riguarda le tue domande su quale ambiente migliore favorisce TDD e tali, i miei due centesimi è che il sistema di gestione di costruzione conta molto meno di ciò che è nel file di configurazione stesso. Il file Ant o MSBuild dovrebbe avere gli obiettivi che fanno il test. Con MSBuild o Ant, non c'è bisogno di utilizzare suite di test di MS. È comunque possibile utilizzare NUnit o qualsiasi altra cosa che si desidera. Questo significa che non importa se TFS sta chiamando il file MSBuild, o se CruiseControl è, o se è TeamCity. L'intelligenza sono tutti nel file di configurazione e gli strumenti che si integrano con esso.

La mia scelta personale, non è quello di ottenere bloccato in modo di fare le cose di TFS, dal momento che si dispone di molta più libertà per molto meno costi con gli strumenti di test open-source di ricchezza che sono là fuori. TFS sta per ricevere un importante aggiornamento, pure. Se avete intenzione di andare con TFS, il mio consiglio è di aspettare almeno fino al 2010 viene rilasciato. Concentrarsi sul rendere i file MSBuild buone come possono essere in questo momento.

Detto questo, devo ammettere che TFS ha uno dei sistemi di compilazione più belle là fuori (il 2005 è stato terribile, il 2008 è stato bello). Essere in grado di personalizzare facilmente le notifiche e il processo di rilascio tutto dentro il codice .NET era abbastanza fresco - si ha molto più controllo centrale sulle costruire e rilasciare la politica di quanto abbiamo fatto con CruiseControl.NET.

Così ho usato TFS e SVN / CCNet. Non posso parlare molto da TeamCity. Ma IMO un sistema di gestione di build dovrebbe essere abbastanza agnostico a ciò che viene costruito e come è in fase di costruzione. Per noi, il controllo extra nel processo di gestione stampa che TFS ci ha portato non era abbastanza di un vantaggio per noi per giustificare la notevolmente aumentato sforzo amministrativo di una soluzione completamente integrata TFS. Né era abbastanza per giustificare l'extra costo per licenza di TFS, che può essere significativo.

Answer 5

Il vecchio TFS Costruire è basata XAML e molto ingombrante e non bello lavorare con. Detto questo, il nuovo sistema di compilazione TFS 2015 è passi da gigante migliori, ed è scritto basato con un sacco di ganci web ed integrazioni 3rd party; molto simile alla squadra della città. Inoltre, TFS ora supporta Git, in modo da non sono più confinata utilizzando versione di Team Foundation Control (TFVC). Inoltre, con TFS è possibile utilizzare il proprio impianto on-prem, o si può usufruire di una soluzione hosted attraverso visualstudio.com. TFS è grande perché è uno ambiente completamente integrato (elementi di lavoro, la pianificazione, costruzione, collaudo, implementazioni), mentre squadra della città è solo una soluzione di accumulo. Quando questa domanda è stato originariamente chiesto nel 2010 avrei consigliato mani squadra della città verso il basso. Ora, però, il 2 sono molto competitivi. Direi che sarebbe forse bollire fino a, se si desidera un all-in-one, quindi andare con TFS, ma se siete alla ricerca di puro solo un sistema di compilazione, quindi squadra della città.

Answer 6

Confrontando TeamCity a Visual Studio Team Services (l'ultima offerta basata su cloud di Microsoft):

• Entrambi funzionano grande per implementare un processo di integrazione continuo

• TeamCity è più maturo e tutto funziona.

• Visual Studio Team Services al contrario è in continua evoluzione al passo con TeamCity e alcune cose semplicemente non funzionano bene (ad esempio, provate innescando build basata su percorsi che hanno le modifiche dal Git - la documentazione è debole e la funzione per sé solo non funziona (a partire da agosto 2016))

• Visual Studio Team Services rende facile avere solo agenti cloud-based che esegue il build (il rovescio della medaglia però è che ognuno ha a che fare un tiro pulito del vostro repository per ogni generazione che può aggiungere un minuto o più per la build). Entrambi possono anche supportare gli agenti di build locali che non hanno bisogno di pulire la directory di lavoro per ogni generazione fresco.

Ma in entrambi i casi vi consiglio vivamente di guardare anche CakeBuild che si muove la maggior parte delle informazioni di configurazione su come per fare una build fuori dal sistema CI e in codice C # che è nella vostra Git repository insieme con tutti gli altri il codice sorgente. Con CakeBuild è possibile eseguire la stessa corporatura localmente come verrà eseguito nel sistema di CI e se avete bisogno di tornare indietro di un mese per costruire una versione specifica di avere il codice sorgente e lo script di build per farlo.

Con CakeBuild in luogo si sono ora liberi di passare facilmente tra TeamCity e Visual Studio Team Services.

L'unico aspetto negativo di CakeBuild è che tutti i tuoi passi di compilazione vengono raggruppati in un unico compito nel sistema di CI che rende la segnalazione un po 'meno bello e possono comportare qualche lavoro extra per ottenere i risultati dei test fuori in un formato che il sistema di reporting CI può usare.

Answer 7

  

MS è anni indietro nel TDD / zona CI

Essendo uno che ha TDD'd per 4 anni lei ha ragione. MS è ancora nemmeno la promozione che né offrono strumenti che funzionano bene con il flusso TDD.

Non rimanere bloccati trattare con Visual Studio per ogni tipo di automazione, controllo del codice sorgente, o periodo di flusso di lavoro agile (smettere di usare TFS per favore !!). Quella roba anche se dicono è "nuovo" è monolitica e viene sempre con problemi di strani e gonfiare. E 'sempre doloroso.

Ho usato squadra della città ed è semplicemente incredibile, le cose funzionano, è progettato per l'usabilità, ed è semplicemente progettato bene e compatibile con la maggior parte tutti gli strumenti di test, ecc Belle Visual Studio uso per il codice, nient'altro. Cercare strumenti di origine esterna e aperto per aiutare a costruire un CI migliore. Il "si può fare tutto a destra in VS" vendere non è vendere, e non funziona. Persone oggigiorno sono abituati e che unisce sempre diversi strumenti da fuori per fare le cose. Basandosi su tutti i set di strumenti di MS non è solo la strada da percorrere IMO per .NET. MS piace vendere "hey si può solo fare tutto bene qui". Ma si finisce con niente, ma il dolore quando si va questa strada e bere il loro koolade (TFS, MS Fakes, ecc.).

Se avete intenzione di fare TDD, che sicuramente non si desidera essere utilizzando tutti gli strumenti MS. Potrai essere sia spinto verso il basso "il loro modo" di fare le cose, che è spesso proprietari e / o gonfiore quando si tenta di TDD con i loro strumenti o essere totalmente restrittiva. Per TDD è necessario essere in grado di avere una certa flessibilità e scelte quando si decide di livello in diversi quadri di prova, biblioteche affermazione, ecc

Octopus sulla parte superiore della squadra della città, ed è stellare ... vi sarà semplicemente innamorarsi di esso come sviluppatore o per chiunque fare DevOps.

Smettere di cercare di fare affidamento su Microsofts continuato fallimento di offerte strumento agile

Iniziare la ricerca fuori dagli schemi e provare nuove cose è quello che continuo a ripetere al mondo .NET, me che sono uno sviluppatore .NET in passato e che ha provato nuove cose al di fuori del mondo MS.