Cruise Control .Net vs Team Foundation Build [chiuso]

Question

Il nostro team sta configurando build di integrazione notturna e continua.Possediamo Team Foundation Server e potremmo utilizzare Team Foundation Build.Ho più familiarità con CC.Net e mi oriento in questo modo, ma il management vede tutti i soldi spesi per TFS e vuole usarlo.

Alcune cose che mi piacciono di più di CC.Net sono la flessibilità delle notifiche e la facilità di implementare script personalizzati.

Se hai esperienza con entrambi i prodotti, quale preferisci e perché?

Answer 1

Li ho usati entrambi.Immagino che dipenda da ciò che valorizza la tua organizzazione.

Dato che hai familiarità con CC Net, non ne parlerò molto.Sai già cosa lo rende bello.

Ecco cosa mi piace di Team Foundation Build:

• Costruisci agenti.È molto semplice trasformare qualsiasi scatola in una macchina di costruzione ed eseguire una costruzione su di essa.MSFT ha capito bene questo.
• Segnalazione.Tutti i risultati di build rilevanti (test incluso) vengono archiviati in un database SQL e riportati tramite SQL Server Reporting Services.Questo è uno strumento estremamente potente per tracciare grafici dei risultati di build e test nel tempo.CC Net non ha questo integrato.
• Puoi eseguire personalizzazioni simili tramite MSBUILD.Fondamentalmente è come usare NAnt con CC Net

Ecco cosa mi fa impazzire riguardo a Team Foundation Build:

• Per creare progetti C++/CLI (o eseguire unit test...?) l'agente di compilazione deve avere installato VSTS Dev o Team Suite.Questo, amici, è semplicemente pazzesco.
• Deve essere collegato alla nave madre TFS

Se ti trovi in ​​una grande organizzazione con molti capi che hanno budget enormi e rapporti amorevoli (e non fraintendermi, questo ha un valore enorme) OPPURE hai bisogno di espanderti fino a diventare una build farm multi-macchina, lo farei preferisci Team Foundation Build.

Se la tua azienda è più snella, resta fedele a CC Net e sviluppa le tue soluzioni di reporting.Questo è quello che abbiamo fatto.

Finché non siamo stati acquisiti.E ho ottenuto TFS: P

Answer 2

Presumo che poiché possiedi TFS lo utilizzerai per il controllo della versione.In tal caso propenderei per Team Foundation Build.Detto questo sono più o meno d'accordo Nick.

Ho scritto il Integrazione CruiseControl.NET per TFS.Funziona bene e ti offre le stesse capacità di costruzione a cui sei abituato.Per me, il vantaggio principale di CC.NET è che è completamente estensibile e si integra con tutti i principali sistemi SCM e build esistenti.Il motivo principale per cui ho scritto l'integrazione CC.NET in TFS è che in TFS2005 il sistema di compilazione non disponeva del supporto CI immediato.Tuttavia la versione TFS2008 è molto migliorata e il team continua a migliorarla molto attivamente per le versioni future di TFS.

Il motivo principale per passare a TFS Build sarebbe che riporti automaticamente le informazioni sulla build in TFS che aiuta a completare il quadro di sviluppo del software in termini di reporting.Si integra perfettamente anche con il lato di tracciamento degli elementi di lavoro di TFS e all'interno dell'IDE (sia in Visual Studio che in Eclipse).

Detto questo, se hai grandi investimenti in script Nant che fanno molto di più che compilare e testare il tuo codice o hai già una soluzione di reporting fatta in casa, potresti voler restare con quello che hai.

Answer 3

Il vero valore di Team Foundation Build è che associa changeset ed elementi di lavoro alle build.

Ciò consente un paio di scenari utili:

• Puoi esaminare un elemento di lavoro e scoprire in quale build è incluso
• Puoi esaminare una build e vedere quali modifiche al codice (e elementi di lavoro) include

Poi ovviamente ci sono i report basati su queste informazioni.Ma anche questi collegamenti da soli sono utili per i tipi non manageriali.

Dai un'occhiata a www.tfsbuild.com per "ricette" su diverse configurazioni di Team Build.

Answer 4

SVN è uno strumento OK di gran lunga superiore, non è vero, SVN vs.TFS è simile a un pick-up Ford rispetto a una Mercedes 500, fa il suo lavoro ma non è carino né comodo, la fusione ha molto a desiderare.Preferisco lo strumento di fusione TFS in quanto sembra che lo sviluppatore di ramificazione sia proprio lì a lavorare con te, ecco quanto è intelligente.Il nostro SVN interno sembrava essere molto danneggiato, questo è il motivo per cui l'abbiamo abbandonato e siamo passati a TFS e non ci siamo guardati indietro.L'accantonamento dei changeset è meraviglioso per un reparto di sviluppo agile, attualmente ha più di 270 ingegneri su TFS senza problemi o problemi, SVN semplicemente non era in grado di gestire quel tipo di carico senza che qualcuno avesse problemi.

Preferisco CC.NET semplicemente per gli strumenti che abbiamo sviluppato internamente per estendere le funzionalità di reporting e amministrazione.La build TFS è tuttavia strettamente integrata e prevediamo un passaggio quando aggiorneremo a SQL 2008

Answer 5

Utilizziamo CruiseControl.net da giugno '07 e per noi ha funzionato benissimo.La parte migliore è che si integra facilmente con SVN, che è un fornitore di controllo del codice sorgente di gran lunga superiore.

Quindi la nostra configurazione è:

• Cruise Control.Net
• SVN
• Trac - per segnalazioni di bug e gestione progetti (si integra perfettamente con SVN)
• nunit - per test unitari

Abbiamo avuto importanti sviluppi paralleli in corso e l'esperienza di ramificazione e fusione è stata spettacolare.Se puoi scegliere, opterei per la configurazione sopra!