Cruise Control .Net vs Team Foundation Compilación

Question

Nuestro equipo está configurando compilaciones 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 cosas que me gustan más 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é?

Answer 1

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

Dado que está familiarizado con CC Net, no voy a hablar mucho de eso. Ya sabes lo que lo hace genial.

Esto es lo que me gusta de Team Foundation Build:

• Agentes construir. 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. Es básicamente el mismo que usar de NAnt con CC Net

Esto es lo que me saca de quicio acerca de Team Foundation Build:

• para construir proyectos C++/CLI (o pruebas de la unidad de carga ... ?) el agente de compilación debe tener instalado VSTS Dev o Team Suite. Esto, amigos, es simplemente loco.
• Debe ser conectado a la TFS nodriza

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

Si tiene 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 obtuve TFS: P

Answer 2

Hemos estado utilizando 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.

Así que nuestra configuración es:

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

Hemos tenido un importante desarrollo paralelo en marcha y la ramificación de un La experiencia de fusión fue espectacular. Si tiene la opción, ¡elegiré la configuración de arriba!

Answer 3

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

Escribí el CruiseControl.NET integration for 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.

Answer 4

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

Esto permite a un par de escenarios útiles:

• Usted puede mirar a un elemento de trabajo y averiguar lo que la edifican está incluido en
• Usted puede mirar a una acumulación y ver los cambios que codifican (y elementos de trabajo) incluye

Luego, por supuesto, los informes se basan en 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.

Answer 5

SVN es una herramienta OK, muy superior no es verdad, SVN vs. TFS es similar a una camioneta Ford vs un Mercedes 500, hace el trabajo pero no es bonita ni cómoda, la fusión tiene mucho que ver ser deseado 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 debido a las herramientas que hemos desarrollado internamente para ampliar la funcionalidad en informes y administración. Sin embargo, la compilación TFS está muy estrechamente integrada y anticipamos un cambio cuando actualicemos a SQL 2008