7

Actualmente estoy en el proceso de configurar un entorno de integración continua en el trabajo. Estamos usando VisualSVN Server y CrusieControl.NET. Ocasionalmente, una compilación fallará y un síntoma es que hay conflictos en la copia de trabajo de CruiseControl.NET. Creo que esto se debe a la forma en que configuré las soluciones de Visual Studio. Es de esperar que mientras más proyectos ejecutemos en este entorno, mejor será nuestra comprensión de cómo configurarlos, de modo que no me pregunto por qué ocurren los conflictos en esta etapa. Para corregir las compilaciones elimino la copia de trabajo y fuerzo una nueva compilación, esto funciona todo el tiempo (actualmente). Entonces mis preguntas son: ¿borrar la copia de trabajo es una parte válida de un proceso de construcción de integración continua y cómo lo hago?Tarea previa a la compilación - eliminación de la copia de trabajo en CruiseControl.NET

He intentado con soluciones que incluyen MSTask y llamar a eliminar desde la línea de comandos, pero no estoy teniendo suerte.

Lo siento por ser tan prolijo - buen trabajo esto es una beta :)

+0

CleanCopy para Subversion está implementado ahora, en la versión 1.4.1. Solo tiene que configurar CleanCopy en true en su configuración – Alex

Respuesta

9

Hacer una eliminación completa antes o después de su compilación es una buena práctica. Esto significa que no hay posibilidad de que su entorno de compilación recoja un archivo desactualizado. Su edificio exactamente en contra de lo que está en el repositorio.

Eliminar la copia de trabajo es posible ya que lo he hecho con Nant.

En Nant tendría un script limpio en su propia carpeta fuera del que quiero eliminar y luego lo invocaría desde CC.net.

Supongo que esto también debería ser posible con un archivo por lotes. Echar un vistazo al comando rmdir http://www.computerhope.com/rmdirhlp.htm

@pauldoo

prefiero mi servidor de CI para hacer un completo eliminan, ya que no quiero ninguna sorpresa cuando voy a hacer una versión de lanzamiento, que siempre se debe hacer desde un estado limpio. Pero debería ser capaz de manejar ambos, no hay razón por la cual no

0

Es muy común y generalmente una buena práctica para cualquier proceso de construcción para hacer una 'limpia' antes de hacer cualquier acumulación significativa. Esto evita que cualquier 'artefacto' de versiones anteriores manche la salida.

Una limpieza es esencialmente lo que está haciendo al eliminar la copia de trabajo.

0

@Brad Barker

medios limpias en apenas acaban con los productos de construcción.

Eliminar la copia de trabajo elimina todo lo demás también (archivos de origen y proyecto, etc.).

En general, es bueno si su máquina de compilación puede operar sin hacer una eliminación completa, ya que esto replica lo que hace un desarrollador normal. Cualquier conflicto que encuentre durante la actualización es una advertencia temprana de lo que pueden esperar los desarrolladores.


@jamie

Para los comunicados formales sí, es mejor hacer un check out completamente limpio. Así que supongo que depende del propósito de la compilación.

2

@jamie: Hay una razón por la cual no se puede hacer una compilación limpia cada vez que se usa un servidor de integración continua: tiempo de compilación.En algunos proyectos en los que he trabajado, las construcciones limpias tardan más de 80 minutos (un proyecto integrado que consiste en miles de archivos C++ para realizar compras y luego compilar contra varios destinos). En este caso, debe ponderar el beneficio de la retroalimentación rápida frente a la probabilidad de que una compilación limpia atrape algo que una compilación incremental no tendrá. En nuestro caso, trabajamos para mejorar y paralelizar el proceso de compilación, al tiempo que permitimos construcciones incrementales en nuestra máquina de CI. Tuvimos algunos problemas porque no estábamos haciendo construcciones limpias, pero al hacer una compilación limpia todas las noches o semanalmente, podía eliminar el riesgo sin perder la respuesta rápida de su máquina CI.

2

Si echa un vistazo a CC.NET jira hay un parche registrado para implementar CleanCopy para Subversion que hace exactamente lo que quiere y simplemente configure CleanCopy igual a verdadero dentro de su bloque de control de origen al igual que con el TFS.

Cuestiones relacionadas