tfs continuous-integration build-automation cruisecontrol.net build

tfs - Cruise Control.Net vs Team Foundation Build



continuous-integration build-automation (5)

Nuestro equipo está estableciendo construcciones de integración continuas y nocturnas. Somos propietarios de Team Foundation Server y podríamos usar Team Foundation Build. Estoy más familiarizado con CC.Net y me inclino de esa manera, pero la administración ve todo el dinero gastado en TFS y quiere usarlo.

Algunas de las cosas que más me gustan de CC.Net son la flexibilidad de las notificaciones y la facilidad de implementación de scripts personalizados.

Si tiene experiencia con ambos productos, ¿cuál prefiere y por qué?

El valor real de Team Foundation Build es que asocia conjuntos de cambios y elementos de trabajo con compilaciones.

Esto permite un par de escenarios útiles:

  • Puede ver un elemento de trabajo y descubrir en qué estructura está incluido
  • Puede ver una compilación y ver qué cambios de código (y elementos de trabajo) incluye

Luego, por supuesto, están los informes construidos sobre esta información. Pero incluso estos enlaces por sí mismos son útiles para tipos que no son de gestión.

Eche un vistazo a www.tfsbuild.com para encontrar "recetas" en diferentes configuraciones de Team Build.

He usado ambos. Supongo que depende de lo que valora tu organización.

Como está familiarizado con CC Net, no hablaré mucho de eso. Ya sabes lo que lo hace genial.

Esto es lo que me gusta de Team Foundation Build:

  • Desarrollar agentes. Es muy simple convertir cualquier caja en una máquina de construcción y ejecutar una construcción en ella. MSFT lo acertó.
  • Informes Todos los resultados de compilación relevantes (prueba incluida) se almacenan en una base de datos SQL y se informan a través de SQL Server Reporting Services. Esta es una herramienta inmensamente poderosa para trazar los resultados de compilación y prueba a lo largo del tiempo. CC Net no tiene esto incorporado.
  • Puede hacer personalizaciones similares a través de MSBUILD. Básicamente es lo mismo que usar NAnt con CC Net

Esto es lo que me lleva a la pared sobre Team Foundation Build:

  • Para compilar proyectos C ++ / CLI (o ejecutar pruebas unitarias ...?) El agente de compilación debe tener instalado VSTS Dev o Team Suite. Esto, amigos, es simplemente loco.
  • Debe estar conectado a la nave nodriza TFS

Si estás en una gran organización con muchos jefes que tienen grandes presupuestos e informes de amor (y no me malinterpreten, esto tiene un gran valor) O tienes que escalar a una granja de construcción de máquinas múltiples, prefiera Team Foundation Build.

Si es una tienda más ágil, quédese con CC Net y desarrolle sus propias soluciones de informes. Eso es lo que hicimos.

Hasta que nos adquirieron. Y tengo TFS: P

Hemos estado usando CruiseControl.net desde junio de 2007 y nos ha funcionado muy bien. La mejor parte es que se integra fácilmente a SVN, que es un proveedor de control de fuente muy superior.

Entonces nuestra configuración es:

  • Cruise Control.Net
  • SVN
  • Trac : para informes de errores y gestión de proyectos (se integra perfectamente con SVN)
  • nunit - para pruebas unitarias

Hemos tenido un gran desarrollo paralela y la experiencia de ramificación y fusión fue espectacular. Si tiene la opción, ¡elegiré la configuración de arriba!

SVN es una herramienta OK, muy superior, no es verdad, SVN vs. TFS es similar a un pickup Ford vs un Mercedes 500, hace el trabajo pero no es bonito ni cómodo, la fusión tiene mucho que desear. Prefiero la herramienta de fusión de TFS, ya que parece que el desarrollador de bifurcación está trabajando contigo, así de inteligente es. Nuestro SVN interno parecía corromperse mucho, esta es la razón por la que lo abandonamos y fuimos a TFS y no hemos mirado hacia atrás. La estantería de conjuntos de cambios es maravillosa para una tienda de desarrollo ágil, actualmente cuenta con más de 270 ingenieros en TFS sin problemas o problemas, SVN simplemente no era capaz de manejar ese tipo de carga sin que alguien tenga problemas.

Prefiero CC.NET simplemente por las herramientas que hemos desarrollado internamente para extender la funcionalidad en informes y administración. Sin embargo, la compilación de TFS está muy integrada y anticipamos un cambio cuando actualicemos a SQL 2008.

Asumo que como posee TFS, lo usará para control de versiones. En ese caso, me inclinaría hacia Team Foundation Build. Dicho eso, estoy más o menos de acuerdo con Nick .

Escribí la integración CruiseControl.NET para TFS . Funciona bien y le ofrece las mismas capacidades de compilación a las que está acostumbrado. Para mí, la principal ventaja de CC.NET es que es completamente extensible y tiene integraciones con todos los principales sistemas SCM y de construcción bajo el sol. La razón principal por la que escribí la integración de CC.NET en TFS es que en TFS2005 el sistema de compilación no tenía soporte CI listo para usar. Sin embargo, la versión TFS2008 ha mejorado mucho y el equipo continúa mejorando activamente para futuras versiones de TFS.

La razón principal para cambiar a TFS Build sería que automáticamente informe la información de compilación a TFS, lo que ayuda a completar la imagen de desarrollo de software en términos de informes. También se integra muy bien con el lado de seguimiento de elementos de trabajo de TFS y dentro del IDE (tanto en Visual Studio como en Eclipse).

Dicho esto, si tiene grandes inversiones en los scripts de Nant que no solo compilan y prueban su código o si ya tiene una solución de generación de informes casera, es posible que desee conservar lo que tiene.