Qual è il set di strumenti più semplice per iniziare con Controllo origine, TDD e CI per Microsoft.Net 2008/2010

Question

Lavoro in un team con altri tre sviluppatori e un analista aziendale che scrive applicazioni aziendali interne. Stiamo principalmente costruendo app in ASP.Net e lo facciamo in un modo molto simile al 2003. È come tornare in una macchina del tempo. Sebbene due degli altri sviluppatori siano propensi a imparare cose nuove, uno degli sviluppatori non lo è. È il tipo che pensa di essere lo sviluppatore più forte in città, e che se non capisce un nuovo strumento entro 5 minuti, ha solo bisogno di costruirsi il proprio. Inoltre, non riconosce lo sviluppo agile, TDD, o fondamentalmente nessuno strumento o metodo benedetto da Microsoft. Egli considera anche il controllo del codice sorgente da qualsiasi cosa diversa da SourceSafe per essere pericoloso. A suo merito, è un brillante programmatore , non solo qualcuno interessato allo sviluppo del software .

Quindi l'unico modo per ottenere il consenso è se uno strumento è davvero facile da usare. Una volta che abbiamo colpito un singolo ostacolo, perderà la fiducia in un modo "Ti ho detto così".

Quindi quale set di strumenti dovrei usare per portarci in un moderno sistema di controllo del codice sorgente, TDD e CI? La scelta ovvia nella mia situazione sembra essere il TFS di Microsoft, ma dubito che potrei ottenere il nostro team di gestione parsimonioso e apatico di spendere i soldi extra (già pensano che MSDN Pro sia troppo).

Fondamentalmente, qual è l'insieme di strumenti più semplice da utilizzare con Controllo origine, TDD e CI per un ambiente .Net 2008/2010?

Answer 1

In ambienti .NET, Microsoft Visual SourceSafe viene utilizzato più di frequente. (ma costa). Accanto a questo puoi optare per SVN o GIT. Git è più recente (e sta guadagnando popolarità). È più facile lavorare con SVN dopo averlo ottenuto.

http://git.wiki.kernel.org/index.php/GitSvnComparison potrebbe aiutare con la vostra decisione.

Answer 2

È sempre difficile introdurre nuovi strumenti se non è possibile creare un consenso. Concentrati sulla costruzione del consenso, piuttosto che sugli strumenti.

SVN è molto buono (con Ankh e TSVN), ma può essere un po 'sorprendente per le persone abituate a SourceSafe.

TDD è una tecnica, piuttosto che un set di strumenti, quindi hai bisogno di libri, blog, ecc. Per gli strumenti che supportano, NUnit o MSTest. L'integrazione continua è un must. CruiseControl.Net è abbastanza buono (anche se un po 'difficile da configurare inizialmente). Considera anche TeamCity.

Avete un sistema di tracciamento dei bug?

Oh, e se il tuo team di gestione è così apatico, prova a smettere.

Aggiornamento: hai detto che non sono tanto "apatici" quanto "hands-off". Domanda: sono davvero disponibili e ti lasceranno spostare le cose? O sono "status quo" - "non è rotto, quindi non aggiustarlo e non scuotere la barca"?

Answer 3

Ci sono molte buone scelte, ma posso personalmente consigliare questi:

• controllo Source: Subversion con TortoiseSVN e Ankh o VisualSVN
• Continuous Integration: CruiseControl.NET
• strumenti TDD: NUnit + il tuo scherno quadro di scelta (Io uso NMock, anche se è un po 'vecchia scuola). Concordo con il commentatore Eric che TestDriven.NET è un must, in particolare se si vuole rendere questo facile!

Questi sono facili da iniziare perché sono tutti prodotti buoni, ragionevolmente molto ben documentati e ampiamente utilizzati (quindi è facile ottenere aiuto).

Answer 4

Non consiglierei di scaricare tutti questi strumenti e metodologie sul tuo team in una sola volta, fai piccoli passi. Introducene uno alla volta. Alcuni arriveranno naturalmente.

Answer 5

Penso che si possa fare un caso davvero ottimo che negli ultimi due anni Agile sia diventato completamente e totalmente accettato da Microsoft. So per certo che le squadre di MVC di Codeplex, MEF e ASP.NET ne sono abbastanza intrise. Io anche penso che che lo studio visivo e parti del team di Windows 7 siano Agili. Considerate anche che Visual Studio 2010 include refactoring pronti all'uso che non hanno molto senso al di fuori del contesto di TDD e che Agile è il modello di gestione progetto predefinito per TFS e un'immagine di una cultura aziendale che è abbastanza diversa da quello degli anni passati inizia ad emergere.

Come per gli strumenti specifici. TFS è OK per il controllo del codice sorgente ma trovo molto pesante e pignolo. Altri hanno menzionato Subversion ma se sei preoccupato per le benedizioni della SM potresti avere una fortuna migliore saltando direttamente su Mercurial. È un SCM più avanzato ma ora è supportato nativamente da Codeplex e ha un'eccellente integrazione con Windows. Non l'ho mai usato, ma sono profondamente innamorato dello strumento con il suo cugino.

Sviluppo basato su test: iniziare con MSTest, non è così liscio come chiunque vorrebbe, ma non è la cosa peggiore del mondo. Vorrei anche raccomandare MbUnit che ha tutte le caratteristiche di NUnit insieme ad un buon supporto per i test di integrazione che probabilmente scriverete per sbaglio mentre state iniziando con i test. Oh, e se hai un maniaco della personalizzazione, lo esorto a dare un'occhiata a XUnit.Net.

Mocking: la scelta è fondamentalmente Rhino Mocks o MoQ. Here's a quick intro I wrote for Rhino Mocks che ripercorre tutte le nozioni di base. Detto questo, il trade off sembra essere più documentazione per RM rispetto a una sintassi molto meno incline agli errori per MoQ.

Corridori di test: se inizi con MSTest noterai che puoi ottenere un significativo aumento di velocità nelle esecuzioni di test utilizzando TestDriven.Net, re-snaer o coderush anziché il test runner integrato. Detto questo, non sottovalutare i test-runner standalone. Possono essere abbastanza buoni ogni tanto. Raccomando vivamente Gallio Icarus runner che viene fornito con MbUnit.

Answer 6

Uno strumento che mi ha incastrato su TDD è TestDriven.Net che inserisce i risultati del test nella finestra Output. Ho mappato questo alla chiave F8 e il guadagno di produttività è superbo; scrivere un test, premere F8 e vedere questo risultati nella finestra di output.

Un suggerimento Devo anche distinguere tra avere test di unità e fare TDD. Ho scoperto che il TDD può essere difficile da spingere in una squadra, mentre; unità, integrazione o test funzionali sono una vendita più facile. Avere una serie di test che consente di risparmiare un'ora dopo un test manuale giorno dopo giorno è una grande vittoria.

Dopo un po 'le persone inizieranno ad apprezzare alcune nuove idee se le stanno aiutando nella loro vita quotidiana. Quindi sarai in grado di introdurre un server di build e allontanarti da SourceSafe.

Answer 7

Voglio ripetere ciò che George Mauer ha detto e suggerire di iniziare con MSTest per il test dell'unità. È proprio lì nella scatola per iniziare con Visual Studio, questo ti aiuterà nella tua causa dato che è "MS benedetta".

Vorrei iniziare con il collaudo di unità e portarlo da lì, dopo alcuni mesi di "guarda quanto è più facile la nostra vita ora abbiamo questi test automatizzati" mi piacerebbe prendere una tacca. Prova ad aggiungere qualcosa come Selenium o WatiN al mix. Una volta completato, porta il tuo server CI in su. "Non sarebbe bello se non dovessimo iniziare tutti questi test manualmente? ..."

Immagino che un SCM decente potrebbe essere un punto critico. SourceSafe è meglio di niente. Forse inizia ad usare Mercurial o Git te stesso? Mostra chi è aperto al cambiamento dei benefici, alla fine il tuo devoto ostinato arriverà quando gli altri intorno a lui vorranno cambiare. Spero che troverà più difficile urlare se è in minoranza.

Dai un'occhiata a http://www.viget.com/extend/effectively-using-git-with-subversion/ per idee con la miscelazione di diversi SCM.

Vorrei anche fare +1 su mxmissile per dire di prendere le cose lentamente. Penso che troverai molto difficile introdurre tutti questi cambiamenti in una volta sola. All'inizio è molto da prendere se non ci si abitua. Prova a scegliere la parte in cui sei più debole o aggiungerai il valore maggiore e accumulerai da lì.

Buona fortuna!