El performance del server de control de versiones cuando se usa CruiseControl (StarTeam o alternativas)

Estamos usando CruiseControl con un server StarTeam y tenemos problemas con el locking del server StarTeam. Nos preguntamos si estamos golpeando el server demasiado duro. A través de 3 máquinas CruiseControl y un total de aproximadamente 30 proyectos, iniciamos session en StarTeam y buscamos modificaciones cada minuto más o less. La mayoría de nuestros proyectos tienen ~ 20,000 files en ellos. ¿Alguien tiene experiencia con las limitaciones de performance en este tipo de escenario con StarTeam?

También me interesan las métricas de performance para CruiseControl con otros sistemas de control de versiones, como TFS, Perforce, SVN, etc. ¿Tienen problemas de escalabilidad al usar CruiseControl y una gran cantidad de proyectos con muchos files?

Tengo cierta experiencia con el uso de Star Team para la continuous integration, aunque usando TeamCity, no CruiseControl. En nuestro caso, las conexiones regulares de TeamCity con StarTeam apenas se registran como un problema en nuestra supervisión del performance.

¿Has mirado los files de logging de StarTeam en tu server? – generalmente ubicado en el directory raíz de la bóveda o hive de su código. Por lo general, encontré los loggings suficientes para solucionar cualquier problema.

Desea examinar el uso del "set de modificación compuesta" como se describe aquí:

¿StarTeam admite "triggers"? En lugar de tener sus máquinas CruiseControl revisando el repository cada minuto para un cambio, usted tendría su máquina StarTeam informando a CruiseControl cuando el código ha sido cambiado tocando un file.

Básicamente, cuando se realiza una actualización en un proyecto, su VCS toca un file que CruiseControl monitorea (como project-a-update.txt). Una vez que se da count de que el file ha cambiado, CruiseControl sabe que debe molestarse en hacer una actualización desde su VCS. Por lo tanto, es un sondeo de un solo file de text por proyecto cada N minutos, en lugar de todo el repository.

Nuestra mayor mejora de performance al ejecutar CC en varios proyectos activos fue instalar un agente de caching MPX en la misma máquina y asegurarnos de que almacenaba los attributes y contenidos de los files. (Bueno, eso y asegurarse de usar ccache en las comstackciones).

La idea de desencadenantes existe en el SDK de StarTeam, pero no estoy seguro de qué tan integrado está con CC. Para verificar si se necesita una compilation, conservamos la última extracción del server en un directory limpio y usamos la list stcmd para comparar los cambios. Esto es muy rápido.

Hasta donde puedo decir, StarTeam no admite activadores. La tarea CruiseControl.NET StarTeam solo admite sondeos, y no he visto ninguna evidencia de que StarTeam admita triggers de forma nativa.

Estoy experimentando exactamente el mismo problema de empujar a StarTeam a su límite. No estoy seguro, pero estoy empezando a pensar que el problema del locking está relacionado con los accesos simultáneos, ya que los problemas ocurren mucho más a menudo cuando un proyecto es muy activo tanto para los desarrolladores como para CruiseControl.

La penalización por sondeos para cambios también está llegando a ser bastante significativa. Peor aún es que la pena se duplica. La primera llamada a StarTeam es una llamada de "hist" para get el set de cambios para generar informes y desencadenar una compilation, luego una llamada de "co" hace una segunda comprobación de todo el tree de origen y verifica si hay algún elemento desactualizado o perdido files. Si alguien puede sugerir una manera de crear un desencadenante alnetworkingedor de un proyecto de StarTeam que elimine cualquiera, me gustaría probarlo.

Un poco de información adicional que pude encontrar.

StarTeam no siempre desconecta a un usuario (o agente en el caso de los accesos de CruiseControl), y puede resultar en tener docenas de conexiones / inicios de session abiertos para el mismo usuario / agente. Desafortunadamente, es muy difícil confirmar si se trata de un problema relacionado porque no puedo sobrecargar el server de manera confiable.

Estamos utilizando una versión anterior de StarTeam que no tiene MPX. Me pregunto si alguien tiene experiencia en el uso de StarTeam en un entorno de continuous integration diferente que sea compatible con el método MPX.

En primer lugar, ¡no tengo experiencia con StarTeam! Aunque tengo experiencia en CruiseControl y subversión.

Puede cambiar el intervalo de su agenda a algo less agresivo que 1 minuto: 3-5 minutos generalmente es aceptable para verificar proyectos y ver si necesitan construcción. Pero acepto que puede haber una razón por la que necesite verificar con mucha frecuencia.

Subversion escala muy bien. Esto se debe a que cada vez que Cruise comtesting si hay una actualización, todo lo que hace es comparar el número de versión local con el número de versión remota del proyecto, no es necesario que verifique cada file. Por lo tanto, la velocidad de esta comprobación no se ve afectada por la cantidad de files en el proyecto.

Espero que esto te ayude.