CI: Hudson con.Net vs CruiseControl.Net

continuous-integration (5)

Trabajo para una tienda .net que busca integrar un servidor CI. Por lo que he visto, Hudson parece ser la opción más popular. Teniendo en cuenta que somos una tienda .net única, ¿Hudson presentará algún obstáculo que CC.NET no hará?

He revisado el soporte de hudson para los marcos de prueba de xunit. A continuación se incluye un breve resumen:

MBUnit/Gallio : hay un complemento pero el desarrollo no parece ser demasiado activo ni la comunidad que lo usa. Por ejemplo, solo hay un issue añadido. Se informó en abril y aún no se ha tocado (agosto). (El equipo de Gallio es compatible con el complemento para CC.Net, su tiempo de respuesta se ve mucho mejor)
MSTest: tiene el mismo problema. Tiene solo dos problemas en el sistema de seguimiento de problemas y un retraso promedio en la respuesta es de 6 meses. (Parece que CC.Net tiene soporte nativo para mstest pero requiere alguna configuración)
nUnidad: el soporte para nunit en hudson parece ser bastante bueno. El equipo de desarrollo es mucho más receptivo y también tiene más errores informados (8 actualmente).

Así que creo que voy a darle una oportunidad a CC.Net.

Hudson es mucho más fácil para los principiantes. Lo usamos para compilar automáticamente y empaquetar C ++ Builder dlls y exes. ¡Piénsalo! No es Java ni C #.

No puedo entender por qué un desarrollador .Net usaría una herramienta Java CI. CruiseControl es una herramienta centrada en Java. Por eso se creó CruiseControl.NET. Integración centrada en .NET.

Si desea configurar un sistema estrechamente integrado, escribirá sus propios complementos para que el sistema haga exactamente lo que desea.

por ejemplo, reúna toda la información de la versión que le interesa y luego escriba los archivos de AssemblyInfo.cs con las versiones en ellos.

No puedo pensar en una sola cosa que Hudson no haya podido hacer para nuestro desarrollo de C #, incluso con las pruebas basadas en MSTest, ahora puede ejecutar y marcar su tendencia con el nuevo complemento (solo funciona si está probando UN conjunto) o mi método que funciona en múltiples montajes.

Supongo que lo único que estaría bien, sería generar datos de cobertura de código e informar sobre eso, no estoy seguro de si CC.net hace eso.

Además, Hudson parece tener un apoyo comunitario mucho más fuerte. Nunca he escuchado de alguien que haya elegido CC.net sobre Hudson si tuviera la opción.

Lo usamos para

Implementar servicios de windows
Implementar servicios web
Ejecute MSTests y muestre tanta información como cualquier prueba de Junit
Mantenga un registro de las tareas bajas, med, alta
Advertencias y errores del gráfico de tendencia.

Puede que estas cosas no sean nada nuevo para Hudson, pero sentí la necesidad de enfatizar nuevamente que Hudson puede manejar esto con un proyecto .net, no hay problema.

Éstos son algunos de los elementos .net incorporados que Hudson admite

Además, Dios no quiera que uses una fuente visual segura, también lo admite . Le recomiendo que eche un vistazo al artículo de Redsolo sobre la creación de proyectos .net utilizando Hudson

No sé casi nada acerca de Hudson. Diré que dado que CC.NET se basa en .NET, tiende a tener muchas tareas e informes integrados y aportados por la comunidad relacionados con el ecosistema .NET:

MSBuild Visual Studio NCover NUnit FxCop etc. etc. etc.

Por lo tanto, si usa estas herramientas, debe verificar cuidadosamente qué tan bien están soportadas "fuera de la caja" por Hudson. Además, si terminas teniendo que escribir complementos personalizados (he hecho algunos para CCNET), generalmente es ventajoso poder usar el lenguaje de desarrollo y el IDE que usas para el desarrollo "normal".