¿Cuál es la mejor manera de configurar un servidor de pruebas de integración?

Question

Al configurar un servidor de integración, tengo dudas sobre cuál es el mejor enfoque con respecto al uso de múltiples tareas para completar la compilación.¿La mejor manera es poner todo en un solo trabajo grande o hacer pequeños dependientes?

Answer 1

Definitivamente quieres dividir las tareas.A continuación se muestra un buen ejemplo de configuración de CruiseControl.NET que tiene diferentes objetivos (tareas) para cada paso.También utiliza un archivo common.build que se puede compartir entre proyectos con poca personalización.

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

Answer 2

Utilizo TeamCity con un script de compilación nant.TeamCity facilita la configuración de la parte del servidor CI y el script de compilación nant facilita la realización de una serie de tareas en lo que respecta a la generación de informes.

Aquí hay un artículo que escribí sobre el uso de CI con CruiseControl.NET. Tiene un script de compilación nant en los comentarios que se puede reutilizar en todos los proyectos:

Integración continua con CruiseControl

Answer 3

El enfoque que prefiero es la siguiente configuración (suponiendo que esté en un proyecto .NET):

• CruiseControl.NET.
• Tareas NANT para cada paso individual.Nant.Contrib para plantillas CC alternativas.
• NUnit para ejecutar pruebas unitarias.
• NCover para realizar cobertura de código.
• FXCop para informes de análisis estático.
• Subversión para el control de fuentes.
• CCTray o similar en todos los cuadros de desarrollo para recibir notificaciones de compilaciones y fallas, etc.

En muchos proyectos, encontrarás diferentes niveles de pruebas y actividades que tienen lugar cuando alguien realiza un check-in.A veces, estos pueden aumentar con el tiempo hasta el punto en que puede pasar mucho tiempo después de una compilación antes de que un desarrollador pueda ver si ha roto la compilación con un registro.

Lo que hago en estos casos es crear tres compilaciones (o tal vez dos):

• Una compilación de CI se activa mediante el registro y realiza una obtención, compilación SVN limpia y ejecuta pruebas ligeras.Lo ideal es que puedas reducirlo a minutos o menos.
• Una compilación más completa que podría ser cada hora (si hay cambios) que hace lo mismo que el CI pero ejecuta pruebas más completas y que requieren más tiempo.
• Una compilación nocturna que hace todo y también ejecuta cobertura de código y análisis estático de los ensamblajes y ejecuta cualquier paso de implementación para compilar paquetes MSI diarios, etc.

La clave de cualquier sistema de CI es que debe ser orgánico y modificarse constantemente.Hay algunas extensiones excelentes para CruiseControl.NET que registran y grafican los tiempos de compilación, etc. para los pasos y le permiten realizar análisis históricos y, por lo tanto, le permiten modificar continuamente las compilaciones para mantenerlas ágiles.Es algo que a los gerentes les resulta difícil aceptar: una caja de construcción probablemente lo mantendrá ocupado durante una quinta parte de su tiempo de trabajo solo para evitar que se detenga.

Answer 4

Usamos construir robot, con la construcción dividida en pasos discretos.Se debe encontrar un equilibrio entre desglosar los pasos de construcción con suficiente granularidad y ser una unidad completa.

Por ejemplo, en mi puesto actual, construimos las subpiezas para cada una de nuestras plataformas (Mac, Linux, Windows) en sus respectivas plataformas.Luego tenemos un solo paso (con algunos subpasos) que los compila en la versión final que terminará en las distribuciones finales.

Si algo sale mal en cualquiera de esos pasos, es bastante fácil de diagnosticar.

Mi consejo es escribir los pasos en una pizarra en términos tan vagos como sea posible y luego basar tus pasos en eso.En mi caso sería:

1. Construir piezas de complemento
   1. Compilar para Mac
   2. compilar para pc
   3. compilar para linux
2. Crear complementos finales
3. Ejecutar pruebas de complementos
4. Construir IDE intermedio (tenemos que iniciar la construcción)
5. Construir el IDE final
6. Ejecutar pruebas IDE

Answer 5

Definitivamente rompería los trabajos.Es probable que realices cambios en las compilaciones y será más fácil localizar los problemas si tienes tareas más pequeñas en lugar de buscar en una compilación monolítica.

De todos modos, deberías poder crear un trabajo grande a partir de piezas más pequeñas.

Answer 6

Buen día,

Mientras habla de pruebas de integración, mi gran (obvio) consejo sería crear y configurar el servidor de prueba lo más cerca posible del entorno de implementación.

</thebloodyobvious> (-:

Saludos, Rob

Answer 7

Divida sus tareas en objetivos/operaciones discretas, luego use un script de nivel superior para unirlas todas de manera adecuada.

Esto hace que su proceso de construcción sea más fácil de entender para otras personas (está documentando sobre la marcha para que cualquier miembro de su equipo pueda retomarlo, ¿verdad?), además de aumentar el potencial de reutilización.Es probable que no reutilice los scripts de alto nivel (aunque esto podría ser posible si tiene proyectos similares), pero definitivamente puede reutilizar (incluso si es copiar/pegar) las operaciones discretas con bastante facilidad.

Considere el ejemplo de obtener la fuente más reciente de su repositorio.Querrá agrupar las tareas/operaciones para recuperar el código con algunas declaraciones de registro y hacer referencia a la información de cuenta adecuada.Este es el tipo de cosas que son muy fáciles de reutilizar de un proyecto a otro.

Para el entorno de mi equipo, utilizamos NAnt ya que proporciona un entorno de secuencias de comandos común entre las máquinas de desarrollo (donde escribimos/depuramos las secuencias de comandos) y el servidor CI (ya que simplemente ejecutamos las mismas secuencias de comandos en un entorno limpio).Usamos Jenkins para administrar nuestras compilaciones, pero en esencia cada proyecto simplemente llama a los mismos scripts NAnt y luego manipulamos los resultados (es decir, archivamos el resultado de la compilación, marcamos las pruebas fallidas, etc.).