continuous-integration build-automation cruisecontrol.net teamcity cruisecontrol

continuous integration - CruiseControl[.Net] vs TeamCity para la integración continua?



continuous-integration build-automation (11)

Asegúrese de que el sistema que elija se adapte a la cantidad de proyectos que necesitará que maneje ...

Yo uso CruiseControl.Net pero no lo recomendaría para la construcción de muchos proyectos ... Tengo una disposición (posiblemente un poco extraña) donde tengo muchas bibliotecas estáticas C ++ que compongo en las aplicaciones. Cada biblioteca depende de otras bibliotecas y las aplicaciones extraen un conjunto de libs y build. Cada lib tiene un conjunto de pruebas. Cada aplicación tiene un conjunto de pruebas. Construyo para 5 compiladores y variaciones de plataformas (de Windows).

Lo primero que encontré fue que los desencadenantes de proyectos de CC.Net no son exactamente lo que necesita y el multiactivador no funciona bien con los desencadenantes de proyectos. La forma en que funcionan los desencadenantes del proyecto (utilizan la comunicación remota para conectarse al servidor donde se almacena el proyecto (incluso si es un proyecto administrado por la misma instancia de CC.Net) y luego extraen todos los proyectos de ese servidor y buscan la lista secuencialmente buscar el proyecto que le interesa ...) significa que no se escala bien. Una vez que obtenga más de una cierta cantidad de proyectos, encontrará que CC.Net está tomando la mayor parte de la CPU para su máquina de construcción.

Por supuesto, es de código abierto, por lo que puede solucionarlo ... Y, estoy seguro de que está bien para un pequeño número de proyectos no interdependientes.

Para obtener más detalles de los problemas que tuve y algunos parches para CC.Net, consulte aquí

Me gustaría preguntarte qué entorno de construcción automatizado consideras mejor, basado en la experiencia práctica. Estoy planeando hacer algo de .Net y algo de desarrollo de Java, así que me gustaría tener una herramienta que admita ambas plataformas.

He estado leyendo y descubrí acerca de CruiseControl.NET , utilizado en el desarrollo de stackoverflow, y TeamCity con su soporte para agentes de compilación en diferentes plataformas de sistema operativo y basado en diferentes lenguajes de programación. Entonces, si tiene alguna experiencia práctica en ambos, ¿cuál prefiere y por qué?

Actualmente, estoy interesado principalmente en la facilidad de uso y administración de la herramienta, y mucho menos en el hecho de que CC es de código abierto, y TC está sujeto a licencias en algún momento cuando tienes muchos proyectos para ejecutar (porque, yo lo necesita para una pequeña cantidad de proyectos).

Además, si hay alguna otra herramienta que cumpla con lo mencionado anteriormente y usted cree que merece una recomendación, siéntase libre de incluirla en la discusión.

He estado usando Teamcity durante los últimos 1 año y medio y teniendo una gran experiencia. He integrado varios proyectos .Net y Java y utilicé herramientas como MSBuild, Maven, etc. Encontré que Teamcity era bastante simple de configurar y trabajar. También logré que CI se ejecute para algunos proyectos sql, lo que fue un poco pesadilla, lo que podría haber sido peor con otras herramientas de CI.
Recientemente me actualicé a Teamcity 8.0.6, que fue sencillo. También Teamcity proporciona una API REST que es muy útil para algunos escenarios. Si está utilizando powershell para automatizar compilaciones, hay disponibles varios scripts de integración de Psake / Teamcity en GitHub

He trabajado en y con las herramientas de Integración Continua desde la que generó Cruise Control (versión de Java). Intenté casi todos ellos en algún momento. Nunca he sido más feliz que con TeamCity. Es muy simple de configurar y aún proporciona una gran cantidad de potencia. La página de estadísticas de compilación que muestra los tiempos de compilación, el recuento de pruebas unitarias, la tasa de aprobación, etc. es muy buena. La página de inicio del proyecto de TeamCity también es muy valiosa. Para proyectos .NET simples, solo puede decirle a TeamCity dónde está la solución y qué ensamblajes tienen pruebas y eso es todo lo que necesita (aparte de la ubicación de control de origen). También hemos usado algunos scripts complicados de MSBuild con él y hemos hecho un encadenamiento de construcción. También pasé por dos mejoras de TeamCity y fueron indoloras.

CruiseControl.NET también funciona bien. Es más complicado de configurar, pero tiene una historia más larga, por lo que es fácil encontrar soluciones en la web. Como CruiseControl.NET es de código abierto, también tiene la opción de agregar o cambiar lo que desee. Había usado CruiseControl.NET desde su lanzamiento y escribí algunos de los códigos iniciales de cc.tray (afortunadamente reescrito por alguien que sabía más).

Cruise, de ThoughtWorks, también se ve bastante bien, pero no veo una razón convincente para que cambie. Si estuviera comenzando un nuevo proyecto, podría intentarlo, pero TeamCity ha hecho un gran trabajo simplificando las cosas simples al tiempo que ha simplificado bastante el complejo.

Editar: Acabamos de actualizar a TeamCity 5.0 hace unas semanas y fue otra actualización sencilla. Nos permitió aprovechar las capacidades mejoradas de cobertura de códigos y el soporte de GIT. Ahora también estamos utilizando la compilación personal y las funciones de confirmación probadas previamente que han estado disponibles por un tiempo. Solo pensé que debería actualizar la respuesta para indicar que TeamCity sigue mejorando y sigue siendo fácil de usar.

He usado tanto CC.net como TeamCity. Tengo la tarea de configurar e instalar TeamCity para mi organización (5 desarrolladores). Nuestra organización utiliza algunas prácticas y herramientas poco comunes (al menos, para organizaciones de nuestro tamaño), como Perforce para el control de código fuente y múltiples agentes de compilación que se ejecutan en sistemas operativos heterogéneos, lo que provocó algunos dolores de cabeza iniciales en la configuración. Sin embargo, el soporte por correo electrónico fue absolutamente de primera clase para configurar todo. Recibí respuestas a mis preguntas tontas en literalmente minutos.

La interfaz es intuitiva y receptiva, además de repleta de funciones. El producto se siente muy caro La configuración es fácil, y la interfaz web es lo suficientemente inteligente como para actualizarse sin reiniciar el agente o los servicios del servidor, ni siquiera actualizar la página.

Siento que estamos usando casi todas las características avanzadas del producto y hasta ahora no hemos encontrado ningún error. Ndependen la integración, las secuencias de comandos NAnt anidadas, el etiquetado de la versión Perforce, lo que sea, lo estamos haciendo.

Recomiendo mucho TeamCity a cualquiera que busque un servidor de integración continua, o cualquier servidor de compilación, realmente.

Los he utilizado con éxito en diferentes proyectos. Desde un punto de vista administrativo y de configuración, Team City es mucho más fácil de tratar. No tiene que hackear archivos .config como lo hace con CC y la configuración es muy sencilla. Como no tienes muchos proyectos, recomendaría Team City sobre CC hasta que llegues al punto de que Team City cuesta $$.

Mi servidor de CI favorito por mucho es Hudson. Fácil de configurar y mantener, muchos buenos gráficos para mostrar tendencias a desarrolladores y no desarrolladores, y gratis.

Estoy utilizando TeamCity actualmente en un proyecto y en general estoy satisfecho con él, pero muchos de los gráficos que genera no son especialmente útiles, y es más complicado de configurar que Hudson.

Dicho esto, TeamCity es potente, gratuito para muchos usos, y tiene una característica clave: Remote Run. Puede "comprometer previamente" su cheque directamente desde IDEA o Eclipse, ejecutar una o más configuraciones de compilación en el servidor de TeamCity, y solo comprometer los cambios si la compilación es exitosa (p. Ej., Las compilaciones y todas las pruebas pasan).

Dado que usted puede poner en marcha tanto TeamCity como Hudson en unas pocas horas, podría valer la pena agarrar ambos y ejecutarlos uno al lado del otro, junto con cualquier otro (como CruiseControl) que pueda imaginar. Si no puede hacer que un servidor de CI suba rápidamente para hacer una comparación lado a lado, al menos tiene un punto de datos para facilitar la instalación y / o configuración.

Recientemente configuré cc .net. Es una gran aplicación, pero requiere un poco de paciencia. Estarás editando archivos de configuración en el bloc de notas mucho :)

Ha existido desde hace un tiempo, por lo que está bien soportado y normalmente puede encontrar a alguien que haya hecho lo que quería hacer antes. La interfaz web también es .net, lo que fue una ventaja para nosotros, ya que somos una tienda de Microsoft.

No he utilizado TeamCity, pero he escuchado bastantes recomendaciones y parece bonito.

Sin querer arrojarle herramientas alternativas :-)

Hudson es una gran alternativa de código abierto, he usado CC y CC.net, y confieso que sí creo que son herramientas fantásticas. Estoy pensando en cambiar a Hudson, ya que parece mucho más fácil de configurar y mantener.

https://hudson.dev.java.net/

Tuve una experiencia configurando y ejecutando CruiseControl (versión Java) en Linux durante mi empresa anterior. Como la mayoría de la gente sugiere, no es la cosa más trivial de configurar. Necesita comprender su marco de trabajo para llegar a la configuración manejable / manejable. Sin embargo, una vez que pasó esa joroba, creo que CruiseControl es lo suficientemente flexible como para permitirle hacer diferentes tipos de cosas para adaptarse a diferentes escenarios.

Además, la documentación de CruiseControl, su página wiki también tiene información útil.

No tengo una experiencia directa con TeamCity. Aunque su función de confirmación previa a la prueba parece bastante interesante.

La otra herramienta CC que puedes darle es Bamboo from Atlassian. Es mucho más fácil de configurar y la interfaz es más agradable. Sin embargo, no es tan flexible como lo que ofrece CruiseControl.

Yo era / soy un gran fan de CC.NET. Actualmente tenemos 5 proyectos en CruiseControl, y funciona muy bien. Escribir archivos de configuración con la mano puede ser doloroso, pero está bien.

Pero .

Después del screencast Kona: Integración continua y Better Unit Testing (el primer 1/3 sobre TeamCity) verificará también TeamCity. Me encanta el tablero de instrumentos de la unidad integrada y la interfaz de configuración.

Creo que todos deberían ver este video antes de elegir CC.NET o TeamCity.

ps: Espero que haya un valioso video de CC.NET en la red también.