Orden de compilación en CruiseControl.NET con dependencias de proyecto

Question

En nuestra tienda de desarrollo de software .NET, tenemos CruiseControl.NET configurado para construir 28 proyectos, algunos de los cuales son interdependientes. Cada proyecto representa aproximadamente un proyecto de Visual Studio o una biblioteca Flex emparejada con pruebas unitarias. Lo que me molesta es que no he encontrado una buena manera de garantizar que los proyectos se construyan en un orden que represente las dependencias.

Esto es lo que estoy haciendo:

1. Todo está en la misma cola de construcción. Hice esto para que las compilaciones se realicen de forma secuencial, por lo que puedo evitar la necesidad de varios directorios de trabajo.
2. Establecí prioridades de cola en los proyectos, lo que pensé que influiría en su orden de compilación. Pero después de leer la documentación con más cuidado, descubrí que simplemente controla la priorización cuando hay varias solicitudes de compilación en una cola.
3. Además de usar desencadenantes de intervalo para iniciar una compilación, utilizo desencadenadores de proyecto para que cuando las dependencias se compilan correctamente, también se generen sus dependientes.

En cierto modo, esta configuración funciona. El principal problema es si alguien realiza cambios en el código tanto en el proyecto A como en el proyecto B, donde el proyecto B depende del proyecto A. A veces, el proyecto B se construirá antes del proyecto A. Debido a que el proyecto A aún no se ha construido, puede a veces causa que el proyecto B se rompa. Esto es temporal, ya que el desencadenante de intervalo hace que el proyecto A se construya más adelante, y su construcción exitosa hace que el proyecto B se reconstruya y se solucione. Lo que quiero evitar es que el proyecto B se construya antes del proyecto A para que la rotura intermedia no pueda suceder.

¿Qué prácticas utiliza para gestionar adecuadamente las interdependencias en un servidor CruiseControl.NET? En este punto, no estoy dispuesto a cambiar a un paquete de integración continua no libre como TeamCity.

Answer 1

No coloque la dependencia en la configuración del proyecto CC.NET. Debe controlar el orden de compilación del proyecto a través del script NAnt. No tiene que construir en un nivel de solución, puede construir en un nivel de proyecto individual.

<target name="Project1" depends="Projects2" description="Builds project 1"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project2" depends="Projects3" description="Builds project 2"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project3" description="Builds Project 3"> 
    <msbuild> 
      <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
      <workingDirectory>C:\dev\ccnet</workingDirectory> 
      <projectFile>CCNet.sln</projectFile> 
      <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
      <targets>Build;Test</targets> 
      <timeout>900</timeout> 
      <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

Puede ejecutar pruebas unitarias en un nivel de proyecto individual, por lo que no es necesario para realizar trabajos duplicados en múltiples proyectos.

Answer 2

¡Le sugiero que no cruce el concepto de un proyecto CruiseControl con un proyecto de estudio visual! Generalmente configuro un proyecto de CC que abarca un cuerpo de trabajo. Para mí, esto significa que el proyecto CC ejecutará un script NAnt. La secuencia de comandos NAnt tiene un control muy detallado sobre lo que hago y cuándo. Esto significa que puedo construir mi solución (¡que sabe qué proyecto construir primero!), Ejecutar mis pruebas de unidad, restablecer una base de datos, implementar algún código, enviar algunos correos electrónicos, hacer algún análisis de código (¡NDepend y NCover son geniales!), Esto significa que tengo un proyecto en CCTray y esto mantiene las cosas más fieles a lo que realmente son. Luego puedo crear un nuevo proyecto en CC para controlar cuando paso de DEV a STAGING y de STAGING a PROD para que podamos "presionar el botón" en esta tarea. Pero esto produce solo 3 proyectos en control de crucero y es considerablemente más amigable para el usuario.

Answer 3

Aunque ya ha aceptado una respuesta, sugeriría algo más: no debería tener dependencias directas entre dos proyectos. Por "directo" quiero decir que cada vez que los binarios en el proyecto A cambian, esto no debe significar que los use automáticamente para construir el proyecto B.

El proceso de actualización de estas referencias debe ser controlado (por usted); inevitablemente terminarás con muchas compilaciones rotas para el proyecto B.

Tiendo a mantener todos los binarios externos bajo lib directorio (y subdirectorios) bajo control de fuente y actualizarlos solo cuando decida hacerlo. Y por "externo" me refiero a las bibliotecas de terceros y las de otros proyectos en mi compañía (ejemplo: http://code.google.com/p/projectpilot/source/browse/#svn/trunk/lib)