¿Qué debería incluir un script de MSBuild excepto la compilación?

Question

Actualmente estoy intentando configurar CruiseControl.net, y me pregunto cómo dividir mis tareas.

En general, quiero ejecutar Pruebas unitarias (xUnit.net), Generación de archivos de ayuda (Sandcastle) y FxCop.

Ahora me pregunto si debo especificar un nuevo destino en la configuración de msbuild (" Documentación ") y usarlo para ejecutar SandCastle, o si eso pertenece a un script separado. Además, msbuild está diseñado para construir algo, así que supongo que ncover, xunit y FxCop no deberían ser parte de él, ¿o deberían?

¿Cuál es el alcance previsto de msbuild?

Answer 1

Coloque casi todo en los scripts de MSBuild, para que usted y otros desarrolladores puedan ejecutar los mismos pasos localmente a través de la línea de comandos. De lo contrario, cuando algo sale mal con la compilación, tiene que depurarla en el servidor CC. No es una buena experiencia de depuración. Además, desea ejecutar la compilación localmente antes comprometiéndose para asegurarse de que funcione.

Las pocas cosas que no pondría en los scripts de MSBuild son:

• Actualización de SVN, ya que CC tiene que hacer esto de todos modos, y normalmente no quieres actualizar cuando haces una compilación local. (Bueno, do escribo svn up & amp; & amp; msbuild con bastante frecuencia, pero eso es tan breve que no necesito poner esto en un script).
• Creación y publicación de informes de compilación; de nuevo, este es el dominio de CC, y no es útil a nivel local

En cuanto a la estructuración de sus archivos de MSBuild, querrá un " maestro " script de compilación que puede usar para compilar todo o solo algunos objetivos, por ejemplo

• MSBuild / t: Build para simplemente construir el código de manera incremental
• MSBuild / t: Rebuild para una reconstrucción limpia
• MSBuild / t: UnitTest para simplemente realizar pruebas unitarias
• MSBuild para la opción más frecuente, por ejemplo, equivalente a t:Build;UnitTest
• MSBuild / t: All para compilar el código, la documentación y la configuración de manera limpia, ejecutar todas las pruebas y empaquetar los resultados

También puede agregar " acceso directo " objetivos para las variaciones populares.

Tener un solo archivo de compilación principal no significa que todo esté definido en este único archivo; puede incluir otros archivos msbuild y / o llamar a msbuild de forma recursiva para organizar su compilación. Por ejemplo:

• El archivo maestro .proj debe ser relativamente simple; principalmente, debe definir elementos específicos del proyecto, como la lista de soluciones para compilar, y anulaciones específicas del proyecto
• Deje que el archivo maestro incluya un único archivo .targets que contenga objetivos y propiedades predeterminadas; esfuércese por mantener este proyecto neutral y reutilizable.
• Si el archivo .targets es demasiado grande, divídalo en archivos separados, por ejemplo. Uno para código, otro para ayuda y documentación, otro para configuración y empaquetado. Deje que su archivo principal .targets incluya esos subarchivos, de modo que su archivo .proj solo necesite incluir un solo archivo
• Del mismo modo, puede dividir el archivo .proj maestro si es necesario, por ejemplo. por subsistema.

Answer 2

Tengo un script de compilación para proyectos individuales, y simplemente los encadeno desde un archivo de compilación second al crear una suite ... por ejemplo, mi archivo de compilación protobuf-net maneja el control de versiones (SVN) , compilación (MSBuild + NAnt para mono), testing (NUnit), packaging (zip), etc. Es su proceso de compilación; haga lo que necesita ;-p también podría, por ejemplo, hacer implementación y documentación si quisiera.

También depende de cómo trabajes; Si está utilizando CruiseControl, puede manejar mucho de esto por usted. Para mí, me gusta una línea de comandos " compilación " paso.