Cruise Control .Net vs Team Foundation Build [cerrado]

Question

Nuestro equipo está configurando compilaciones de integración continua y nocturna.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 gerencia 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 implementar 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 valore su organización.

Como usted está familiarizado con CC Net, no hablaré mucho sobre eso.Ya sabes qué lo hace genial.

Esto es lo que me gusta de Team Foundation Build:

• Agentes de construcción.Es muy sencillo convertir cualquier caja en una máquina de construcción y ejecutar una compilación en ella.MSFT acertó en esto.
• 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 registrar los resultados de las pruebas y las construcciones a lo largo del tiempo.CC Net no tiene esto integrado.
• Puede realizar personalizaciones similares a través de MSBUILD.Es básicamente lo mismo que usar NAnt con CC Net

Esto es lo que me vuelve loco 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 una locura.
• Debe estar conectado a TFS Mothership.

Si estás en una organización grande con muchos jefes que tienen presupuestos enormes e informes de amor (y no me malinterpretes, esto tiene un valor enorme) O necesitas escalar a una granja de construcción de múltiples máquinas, yo Prefiero Team Foundation Build.

Si su negocio es más eficiente, 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

Supongo que, como posee TFS, lo usará para el control de versiones.En ese caso me inclinaría por Team Foundation Build.Dicho esto, estoy bastante de acuerdo con Mella.

escribí el Integración CruiseControl.NET para TFS.Funciona bien y le brinda 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 los principales sistemas SCM y de compilación que existen.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 mejorándola de forma muy activa para futuras versiones de TFS.

La razón principal para cambiar a TFS Build sería que reporta automáticamente la información de compilación a TFS, lo que ayuda a completar el panorama del 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 scripts Nant que hacen más que solo compilar y probar su código o si ya tiene una solución de informes casera, es posible que desee seguir con lo que tiene.

Answer 3

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 mirar un elemento de trabajo y descubrir en qué compilación está incluido.
• Puede mirar una compilación y ver qué cambios de código (y elementos de trabajo) incluye

Luego, por supuesto, están los informes creados sobre esta información.Pero incluso estos vínculos por sí solos son útiles para personas que no son de gestión.

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

Answer 4

SVN es una herramienta aceptable, muy superior, no es cierto, SVN vs.TFS es similar a una camioneta Ford versus una 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 TFS, ya que parece que el desarrollador de ramificación está ahí trabajando contigo, así de inteligente es.Nuestro SVN interno pareció corromperse mucho, esta es la razón por la que lo abandonamos y fuimos a TFS y no miramos atrás.La estantería de conjuntos de cambios es maravillosa para un taller de desarrollo ágil, actualmente tengo más de 270 ingenieros en TFS sin problemas, SVN simplemente no era capaz de manejar ese tipo de carga sin que alguien tuviera problemas.

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

Answer 5

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

Entonces nuestra configuración es:

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

Hemos tenido un importante desarrollo paralelo y la experiencia de ramificación y fusión fue espectacular.Si tienes la opción, elegiría la configuración anterior.