Tarea previa a la compilación: eliminar la copia de trabajo en CruiseControl.NET

Question

Actualmente estoy en el proceso de configurar un entorno de integración continua en el trabajo.Estamos utilizando VisualSVN Server y CrusieControl.NET.En ocasiones, una compilación falla 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.Con suerte, cuantos más proyectos ejecutemos en este entorno, mejor comprenderemos cómo configurarlos, por lo que no me pregunto por qué ocurren los conflictos en esta etapa.Para arreglar las compilaciones, elimino la copia de trabajo y fuerzo una nueva compilación; esto funciona siempre (actualmente).Entonces mis preguntas son:¿Eliminar la copia de trabajo es una parte válida de un proceso de compilación de integración continua y cómo lo hago?

Probé soluciones que incluyen MSTask y llamar a eliminar desde la línea de comando, pero no tengo suerte.

Perdón por hablar tanto. Buen trabajo, esta es una versión beta :)

Answer 1

Realizar una eliminación completa antes o después de la 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 comparación con lo que hay en el repositorio.

Es posible eliminar la copia de trabajo como lo hice 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.Eche un vistazo al comando rmdir http://www.computerhope.com/rmdirhlp.htm

@pauldoo

Prefiero que mi servidor CI realice una eliminación completa, ya que no quiero ninguna sorpresa cuando vaya a realizar una versión de lanzamiento, que siempre debe realizarse desde un estado limpio.Pero debería poder manejar ambos, no hay razón para que no

Answer 2

@jamie:Hay una razón por la que es posible que no pueda realizar una compilación limpia cada vez que utiliza un servidor de integración continua: el tiempo de compilación.En algunos proyectos en los que he trabajado, las compilaciones limpias tardan más de 80 minutos (un proyecto integrado que consta de miles de archivos C++ para verificar y luego compilar en múltiples objetivos).En este caso, debe sopesar el beneficio de la retroalimentación rápida con la probabilidad de que una compilación limpia detecte algo que una compilación incremental no captará.En nuestro caso, trabajamos para mejorar y paralelizar el proceso de compilación y al mismo tiempo permitir compilaciones incrementales en nuestra máquina de CI.Tuvimos algunos problemas porque no estábamos haciendo compilaciones limpias, pero al hacer una compilación limpia todas las noches o semanalmente se podía eliminar el riesgo sin perder la rápida retroalimentación de su máquina de CI.

Answer 3

Si revisa CC.NET jira hay un parche registrado para implementar CleanCopy para Subversion que hace exactamente lo que desea y simplemente establece CleanCopy igual a verdadero dentro de su bloque de control de fuente, al igual que con el de TFS.

Answer 4

Es muy común y, en general, una buena práctica que cualquier proceso de compilación realice una "limpieza" antes de realizar cualquier compilación importante.Esto evita que cualquier "artefacto" de compilaciones anteriores contamine la salida.

Una limpieza es esencialmente lo que se hace al eliminar la copia de trabajo.

Answer 5

@Brad Barker

Limpiar significa simplemente eliminar los productos de construcción.

Al eliminar la copia de trabajo, también se elimina todo lo demás (archivos fuente y de proyecto, etc.).

En general, es bueno si la máquina que construye puede funcionar sin realizar 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 sus desarrolladores.

---

@jamie

Para lanzamientos formales, sí, es mejor realizar una compra completamente limpia.Supongo que depende del propósito de la construcción.