¿Cuál es el conjunto más fácil de herramientas para comenzar con Source Control, TDD y CI para Microsoft.Net 2008/2010

Question

Trabajo en equipo con otros tres desarrolladores y un analista de negocios que redactan aplicaciones comerciales internas. Principalmente, estamos creando aplicaciones en ASP.Net, y lo hacemos de una forma muy 2003-ish. Es como regresar en una máquina del tiempo. Aunque dos de los otros desarrolladores están dispuestos a aprender cosas nuevas, uno de los desarrolladores no. Es del tipo que piensa que es el desarrollador más fuerte de la ciudad, y que si no entiende una nueva herramienta en 5 minutos, entonces solo necesita construir la suya propia. Tampoco reconoce el desarrollo ágil, TDD o básicamente cualquier herramienta o método no bendecido por Microsoft. Incluso considera que el control de fuente de algo que no sea SourceSafe es peligroso. Para su crédito, él es un brillante programador, simplemente no alguien interesado en desarrollo de software.

Por lo tanto, la única manera en que puedo obtener un consenso es si una herramienta es realmente fácil de usar. Una vez que golpeemos un inconveniente, perderá la fe en un tipo de "te lo dije".

Entonces, ¿qué conjunto de herramientas debo usar para introducirnos en un moderno sistema de control de fuente, TDD y CI? La opción obvia en mi situación parece que sería el TFS de Microsoft, pero dudo que pueda conseguir que nuestro equipo de gestión ahorrativo y apático gaste el dinero extra (ya piensan que MSDN Pro es demasiado).

Básicamente, ¿cuál es el conjunto de herramientas más fácil de usar con Source Control, TDD y CI para un entorno .Net 2008/2010?

Answer 1

En entornos .NET, Microsoft Visual SourceSafe se usa con mayor frecuencia. (pero cuesta). Al lado de eso puedes optar por SVN o GIT. Git es más reciente (y gana popularidad). Es más fácil trabajar con SVN una vez que lo tienes.

http://git.wiki.kernel.org/index.php/GitSvnComparison podría ayudar con su decisión.

Answer 2

Siempre va a ser difícil introducir nuevas herramientas si no se puede construir un consenso. Enfóquese en construir el consenso, en lugar de las herramientas.

SVN es muy bueno (con Ankh y TSVN), pero puede ser un poco sorprendente para las personas que usan SourceSafe.

TDD es una técnica, en lugar de un conjunto de herramientas, por lo que necesita libros, blogs, etc. Para herramientas que lo admitan, NUnit o MSTest. La integración continua es imprescindible. CruiseControl.Net es bastante bueno (aunque un poco difícil de configurar inicialmente). Considera también TeamCity.

¿Tiene un sistema de seguimiento de errores?

Ah, y si su equipo de gestión es tan apático, considere renunciar.

Actualización: has dicho que no son tanto "apáticos" como "sin manos". Pregunta: ¿están realmente fuera de lugar y le permitirán mover las cosas? ¿O son "status quo" - "no está roto, así que no lo arregles y no balancees el barco"?

Answer 3

Hay muchas buenas opciones, pero personalmente me puede recomendar los siguientes:

• control Fuente: Subversion con TortoiseSVN y Ankh o VisualSVN
• integración continua: CruiseControl.NET
• herramientas TDD: NUnit + su marco de referencia burlón (Yo uso NMock, aunque es un poco viejo). Estoy de acuerdo con el comentarista Eric en que TestDriven.NET es imprescindible, especialmente si desea hacerlo más fácil.

Estos son fáciles de usar porque son buenos productos, razonablemente bien documentados y ampliamente utilizados (por lo que es fácil obtener ayuda).

Answer 4

No recomendaría descargar todas estas herramientas y metodologías en su equipo a la vez, dar pequeños pasos. Presentar uno a la vez. Algunos vendrán naturalmente.

Answer 5

Creo que se puede argumentar muy bien que, en los últimos dos años, Microsoft ha acogido total y completamente a Agile. Sé con certeza que los equipos Codeplex, MEF y ASP.NET MVC están bastante inmersos en él. También creo que que el estudio visual y las partes del equipo de Windows 7 son ágiles. También considere que Visual Studio 2010 incluye refactorizaciones listas para usar que no tienen mucho sentido fuera del contexto de TDD y que Agile es la plantilla de administración de proyectos predeterminada para TFS y una imagen de una cultura corporativa que es bastante diferente del de años anteriores comienza a surgir.

En cuanto a herramientas específicas. TFS está bien para el control de fuente pero me parece muy pesado y meticuloso. Otros han mencionado a Subversion, pero si te preocupan las bendiciones de MS, tal vez tengas más suerte yendo directamente a Mercurial. Es un SCM más avanzado, pero ahora es compatible de forma nativa con Codeplex y tiene una excelente integración de Windows. Nunca lo he usado, pero estoy en un profundo amor por las herramientas con su primo git.

Desarrollo impulsado por pruebas: Comience con MSTest, no es tan resbaladizo como a nadie le gustaría, pero no es lo peor del mundo. También recomendaría MbUnit, que tiene todas las funciones de NUnit, junto con un buen soporte para las pruebas de integración que probablemente va a escribir por accidente cuando comience con las pruebas. Ah, y si tienes un fanático de la personalización, lo instaría a mirar XUnit.Net.

Burlarse: La elección es básicamente Rhino Mocks o MoQ. Here's a quick intro I wrote for Rhino Mocks que repasa todos los aspectos básicos. Dicho esto, la compensación parece ser más documentación para RM frente a una sintaxis muy levemente propensa a errores para MoQ.

Corredores de prueba: si comienza con MSTest notará que puede obtener un impulso de velocidad significativo en las ejecuciones de prueba utilizando TestDriven.Net, resharper o coderush en lugar del corrector de prueba integrado. Dicho esto, no subestimes a los corredores de prueba independientes. Pueden ser bastante buenos de vez en cuando. Recomiendo encarecidamente el corredor Gallio Icarus que viene con MbUnit.

Answer 6

Una herramienta que me metió en TDD es TestDriven.Net que pone los resultados de la prueba en la ventana de resultados. Asigné esto a la tecla F8 y la ganancia de productividad es excelente; escriba una prueba, presione F8 y vea esto resultados en la ventana de salida.

Una sugerencia También tengo que diferenciar entre tener pruebas unitarias y hacer TDD. He descubierto que TDD puede ser difícil de impulsar para un equipo, mientras que; unidades, integración o pruebas funcionales son una venta más fácil. Tener un montón de pruebas que ahorran una hora pasando por una prueba manual día tras día es una gran victoria.

Después de un tiempo, las personas comenzarán a apreciar algunas ideas nuevas si les está ayudando en su vida diaria. Luego, podrá introducir un servidor de compilación y alejarse de SourceSafe.

Answer 7

Quiero hacerme eco de lo que ha dicho George Mauer y sugerir comenzar con MSTest para su unidad de prueba. Está justo en el recuadro para comenzar con Visual Studio, esto ayudará en su causa ya que es "MS blessed".

Empezaría con las pruebas unitarias y lo tomaría desde allí, después de unos meses de "ver qué tan fácil es nuestra vida ahora tenemos estas pruebas automatizadas" Lo tomaría un nivel superior. Considere añadir algo como Selenium o WatiN a la mezcla. Una vez que lo hagas, sube tu servidor de CI. "¿No sería genial si no tuviéramos que comenzar todas estas pruebas manualmente? ..."

Supongo que un SCM decente podría ser un punto de fricción. SourceSafe es mejor que nada. ¿Quizás comiences a usar Mercurial o Git tú mismo? Muestre aquellos que están abiertos para cambiar los beneficios, eventualmente su desarrollador obstinado aparecerá cuando otros a su alrededor quieran cambiar. Con suerte, le resultará más difícil gritar si está en minoría.

Consulte http://www.viget.com/extend/effectively-using-git-with-subversion/ para obtener ideas con la mezcla de diferentes SCM.

También quiero +1 mxmissile para decir que tome las cosas lentamente. Creo que le resultará muy difícil presentar todos estos cambios de una sola vez. Es mucho para asimilar al principio si no estás acostumbrado. Intenta elegir la parte en la que más te sientas débil, o agregará el mayor valor y acumulará desde allí.

¡Buena suerte!