software para medir integracion herramientas entrega continua calidad aws c++ build-process continuous-integration

c++ - para - integracion continua jenkins



¿Qué cadenas de herramientas existen para la integración continua con C++? (6)

Visual Build Professional es mi herramienta favorita para unir todas las otras herramientas. Solo Windows, por supuesto, pero se integra con todos los gustos de Visual Studio y una gran cantidad de herramientas de prueba, herramientas de control de origen, rastreadores de problemas, etc. Sin embargo, solo es Windows. Sé que esa no es toda la pila, pero es un comienzo.

Las cadenas de herramientas de Integración continua para .NET, Java y otros lenguajes están relativamente bien definidas, pero el mercado de C ++ parece tener mucha diversidad.

Por "cadena de herramientas" de CI, me refiero específicamente a las herramientas para los scripts de construcción, las pruebas automatizadas, la verificación de estándares de codificación, etc.

¿Qué utilizan los equipos de C ++ para las cadenas de herramientas de CI?


Gday,

En realidad enfrentamos este problema en un sitio donde me estaba contratando anteriormente.

Un tipo se sentó y escribió herramientas, principalmente guiones de shell, para

  1. revisa la base de código actual cada hora más o menos y haz una compilación para verificar si se rompió, y
  2. revisa la última versión mejorada y haz una compilación completa y ejecuta alrededor de 8,000 pruebas de regresión.

Simplemente no pudimos encontrar nada comercialmente disponible para hacer esto y Charlie se sentó y escribió esto en las secuencias de comandos bash shell y se estaba ejecutando en HP-UX.

aplausos, Rob


Otra opción podría ser buildbot .

Está escrito en python, pero no es solo para aplicaciones de Python. Puede ejecutar cualquier script para hacer tu compilación. Si nos fijamos en sus historias de éxito, parece que hay una gran variedad de idiomas.


Al igual que con aparentemente cualquier otra tarea en C ++, apenas estoy cojeando junto con la integración continua. Mi configuración comienza con Eclipse. Lo configuré para generar archivos make para mis proyectos. Tengo scripts ant que hacen las tareas generales de compilación ejecutando ''make all'' o ''make clean'' en los makefiles apropiados. Estos scripts de hormiga son parte de mi proyecto, y debo actualizarlos cuando agregue una nueva configuración de compilación o una pieza nueva al sistema. Aunque no es tan malo.

Yo uso CruiseControl para realmente ejecutar las compilaciones. Cada proyecto (todos ellos) tiene un script ant propio que realiza tareas específicas de compilación (copia de artefactos, resultados de procesamiento), invocando el guión de la tarea del proyecto para hacer el edificio.

Tuve que usar cppunit para mis pruebas y procesar los resultados con un archivo xslt que encontré en alguna parte. También tengo la etiqueta de revisión svn incorrecta en cada compilación porque no puedo encontrar una etiquetadora svn adecuada. Todo lo que puedo encontrar es un código de mitad de año medio completado y personas que argumentan que otras personas lo están haciendo mal.

Me parece que CC es un sistema en extinción, pero no he encontrado nada mejor para C ++. Por otra parte, también siento que C ++ es un lenguaje moribundo, por lo que tal vez sea más grande que esto.


Usamos scons para una integración continua ejecutada por un servidor central de compilación. Algunos proyectos migraron a buildbot .

Ahora estoy entrando en rake y considerando soluciones como las encuestadas en este blog . Fowler menciona que ThoughtWorks ocasionalmente usa rake para sus scripting de compilación en su artículo de Integración Continua .


Implementamos nuestra infraestructura de integración continua de plataforma cruzada C ++ utilizando Parabuild

http://www.viewtier.com/products/parabuild/screenshots.htm

Pudimos integrar todo tipo de herramienta de control de calidad Win / Mac / Linux y es muy fácil de instalar y mantener: se trata de una instalación de un clic en cada plataforma y la interfaz web es muy útil.

Al evaluar varios servidores de integración continua, el problema principal era que tenían un sesgo de Java: Parabuild, por otro lado, encajaba bien en el desarrollo de la plataforma cruzada de C ++ y el flujo de trabajo de QA.