Team Build ahora Painfully Slow

Question

Estamos teniendo problemas de rendimiento con nuestra implementación de Team Foundation Build Server y me estoy quedando sin ideas sobre cómo acelerar las cosas. Ya hemos agregado algunos elementos de PropertyGroup para aumentar el rendimiento en varios pasos (SkipClean, SkipLabel, SkipInitializeWorkspace), pero creo que debemos someternos a una importante reestructuración para solucionarlo. Aquí está nuestra configuración:

• Tenemos alrededor de 40 aplicaciones web que son cada uno muy diferente, pero correr fuera un montón de ensamblados compartidos
• Cada una de estas aplicaciones web tiene su propia solución;
• Hay alrededor de 10 a 25 conjuntos compartidos referenciados por cada una de estas aplicaciones web;
• Existe una definición de compilación que contiene todas las soluciones que se activan en cada check-in en el trunk;

Y aquí es los problemas de fondo que estamos encontrando

• Durante la construcción, se va a construir cada ensamblado compartido tantas veces como se le hace referencia, en lugar de construir una vez y utilizar para cada aplicación
• El tiempo de copiado del archivo es bastante lento para el directorio desplegable. Tiene que estar sobre la red compartida y no tomará una ruta local.
• Cada tantas compilaciones, uno o más de los archivos de salida se "bloquea" y hace que la construcción se rompa incluso si la compilación es correcta.
• Y otra cosa: también he intentado definiciones de compilación separadas, pero hacerlo también forzará que se obtenga otro espacio de trabajo en Obtener la última versión. Prefiero que el servidor de compilación contenga una versión del tronco para construir.

En los últimos meses hemos cedido al letargo e ignorado este problema, pero ahora el tiempo de construcción es de más de una hora a una hora y media.

Estoy jugando con la idea de aprender y cambiar a Cruise Control para un mayor control que tendría. ¿Alguien está en desacuerdo con eso?

Cualquier ayuda es muy apreciada. ¡Gracias!

Answer 1

En primer lugar, parece que todas sus aplicaciones web están incluidas en el mismo Team Project. Si eso es cierto, divídalos en agrupaciones lógicas. Normalmente, un solo proyecto de equipo debe formar parte de un único modelo de implementación.

En segundo lugar, divida los conjuntos compartidos en su propio proyecto de equipo. Una vez movido tiene un par de opciones, puede ramificar el origen o los archivos DLL compilados a los proyectos de equipo que los necesitan. Pueden tener sus propias pruebas de unidad y puede ampliar la creación del equipo para fusionarse automáticamente en una prueba exitosa si así lo desea.

En resumen, debe simplificar su estrategia de compilación.

Answer 2

Hablando de su experiencia personal con la sugerencia de CruiseControl, recuerde que es un "marco" de integración continua. No resolverá todos sus problemas de forma inmediata (construcciones componentes, activando cada cambio de componente, y compilaciones serializadas, aunque mejorará las cosas). Se necesitará bastante configuración (y tal vez incluso personalización) para obtener las cosas como quieras, así que prepárate para invertir algo de tiempo.Por supuesto, obtendrá un pago masivo a largo plazo si su tiempo de construcción se reduce, si no puede ignorar el problema más, vale la pena invertir algo de tiempo en una mejor solución de CI.

Tenga en cuenta que cualquier esfuerzo de CI es tan bueno como las políticas que tiene implementadas. Tuvimos enormes vacíos de política cuando se trataba de etiquetado de versiones, publicación, dependencias, versiones beta de binarios, compilaciones de archivos ... y muchos otros problemas que ni siquiera consideramos en ese momento.

Además, prepárate para dedicar al menos algunos recursos a mantener la cosa. No es un trabajo a tiempo completo (y a mí me encanta hacerlo, ya que produce una mejora continua del proceso). Nuestras personalizaciones nos han llevado de una construcción monolítica de 2 horas de nuestro primer producto a más de 400 componentes en 20 productos que se construyen en paralelo en varias máquinas en unos 20 minutos, por lo que vale la pena.

Answer 3

¿De verdad necesitas construir todo en cada aplicación web? Si los conjuntos compartidos no han cambiado, ¿por qué construirlos una y otra vez?

Aquí es un pensamiento:

1. Que cada aplicación web tiene su propia carpeta \ lib.
2. Coloque cada conjunto compartido en la carpeta lib.
3. Deje que la aplicación web solo haga referencia a conjuntos compartidos desde su carpeta de lib local.
4. comprobar todo en.

ahora una acumulación No se debe comenzar a menos que algo ha cambiado, y la acumulación no incluirá los ensamblados compartidos.

• Debe haber una carpeta central que contenga todos los ensamblados compartidos.
• Cualquier cambio aquí debería propagarse a todas las carpetas locales \ lib.
• Finalmente, cualquier ensamblado compartido debe copiarse en la carpeta central cada vez que cambien.

La idea aquí es tener un proyecto de ensamblaje compartido para conocer solo la carpeta central. Esto simplificará cualquier acción posterior a la construcción necesaria para copiar la construcción.

La carpeta central debe administrarse de tal forma que los cambios se copien en todas las aplicaciones web de referencia.

Answer 4

Así que esto es lo que he hecho, y he reducido la construcción a 9 minutos. Por la cantidad de proyectos que estoy compilando, estoy de acuerdo con eso.

• Creó una solución que contiene todas las bibliotecas compartidas y todas las webs. Hubo mucho trabajo adicional en este paso porque tuve que arreglar un montón de referencias que eran código heredado o almacenadas en varios lugares.
• Lo que terminó ahorrando más tiempo fue realizar un sistema de archivos mover en lugar de una copia de red para todos los archivos de salida. Dado que nuestra ubicación de colocación en realidad se encuentra en el servidor de compilación, tiene sentido.

Para realizar el movimiento, simplemente anulo el objetivo CoreDropBuild dentro de TFSBuild.proj file:

<Target Name="CoreDropBuild" 
     Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' " 
     DependsOnTargets="$(CoreDropBuildDependsOn)" > 
      <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>  
</Target>