Cualquier mejor práctica para escribir scripts de compilación en Ant o MSBuild

Question

Estoy intentando automatizar el proceso de compilación de mis proyectos (tanto java como .net) usando Ant y MSBuild. He leído sobre ellos y sé cómo escribir scripts de compilación en Ant y MSBuild. Pero me pregunto, ¿hay alguna guía o mejores prácticas para escribir scripts de compilación en general? Aquí hay dos que he encontrado, pero me gustaría saber más de otros desarrolladores.

• Al escribir un script de creación, sólo se basan en los artículos que se encuentran en control de origen y están disponibles en la carpeta de trabajo, mientras que de comprobar las fuentes. NO escriba scripts de compilación que sean dependiendo de los elementos que no se mantienen en el control de origen.
• Si un proyecto contiene un conjunto de subsistemas y cada subsistema tiene sus propios scripts de compilación, el archivo de compilación del proyecto solo debe llamar a las secuencias de comando de compilación de los subsistemas. Además, estos archivos deben importar un fichero de construcción común que contiene los objetivos, tales como compilación, pruebas, etc. paquete

que he visto this post así, pero es detallada en el camino de las tareas de escritura. Necesito más pautas de alto nivel, como se mencionó anteriormente.

Estas son las directrices que recogí de las respuestas:

1. Ejecutar cada construyen en un ambiente limpio. Significa que cada script de compilación necesita un objetivo clean.
2. Las secuencias de comandos de compilación generalmente deben incluir compile, package y test objetivos.
3. Si un producto tiene diferentes líneas de desarrollo (por ejemplo, dev, versión), todas ellas deben tener el mismo script de compilación. Sin embargo, se deben pasar diferentes parámetros a estos scripts.
4. Las compilaciones realizadas en líneas de desarrollo generalmente contienen compilación, embalaje, implementación e instalación de pasos. Pero las versiones de la versión incluyen pasos adicionales, como etiquetar el producto y generando registros de cambios/notas de la versión.
5. Las secuencias de comandos de compilación también deben mantenerse en el control de origen.
6. tratar de mantener toda la información de compilación de scripts de construcción, no en servidor de integración continua (bambú, TeamCity, etc.)
7. Si su construcción utiliza un parámetro que puede cambiar en el futuro (por ejemplo, la dirección de red para copiar el generar resultados), no lo codifique en su script de compilación. en su lugar, use los parámetros de compilación para controlarlo más fácilmente.

Answer 1

Si está creando aplicaciones de VisualStudio, es mejor que use msbuild sobre Ant. El comando msbuild hará la compilación usando el archivo de solución que crearon sus desarrolladores, y básicamente emulará la misma compilación que ellos.

Si realmente quiere automatizar todo, eche un vistazo a Jenkins. Tiene un complemento que puede ejecutar msbuild y activará automáticamente una creación cada vez que alguien haga un cambio. Uso una combinación fo msbuild y Ant con Jenkins. Hago la compilación usando msbuild, luego uso Ant para recoger y comprimir todos mis artefactos construidos. Luego, la gente puede descargar los artefactos construidos directamente de Jenkins.

Ahora, con sus aplicaciones Java, tendrá que usar Ant. Uso las siguientes pautas

• Cada secuencia de comandos de construcción necesita un objetivo clean. Este destino elimina los archivos que se agregaron durante el proceso de compilación, devolviendo el directorio de trabajo a un estado antes de que se llevara a cabo el clean.
• sigo lo que hace Maven al utilizar nombres de destino, por lo que mis objetivos son nombres de cosas como limpia, compilar y paquete.
• También siguiendo las pautas de Maven, todos mis archivos integrados se colocan en el directorio target. De esa forma, mi comando de limpieza puede simplemente hacer un <delete dir="${target.dir}/> y limpia todo de forma agradable y brillante.
• Si tengo un subproyecto, cada subproyecto tiene su propio archivo build.xml. Mi archivo maestro build.xml simplemente llama a todos los subproyectos 'build.xml archivos.
• Use Ivy. Es fácil de configurar y fácil de usar.Ya no tiene el problema de almacenar archivos jar en su repositorio de origen, o perder qué versiones de qué archivos jar depende de usted.
• Diablos, si puede, use Maven y termine con eso. Desafortunadamente, la mayoría de los proyectos más antiguos son más difíciles de mavenizar de lo que vale la pena.
• Realice sus compilaciones utilizando Jenkins como servidor de compilación continua. Y, todas las construcciones que abandonan el departamento (UAT, QA y compilaciones de protección) deben ser una compilación de Jenkins.
• Anime a sus desarrolladores a escribir pruebas de Unidad. De hecho, Jenkins puede ejecutar pruebas unitarias y mostrar sus resultados en su página de compilación.
• Use otras cosas como checkstyle, PMD, CPD, Findbugs y otros productos de verificación de código. Y, por supuesto, Jenkins puede ejecutar cada uno de estos y mostrar bonitos gráficos que pueden usarse para mostrarle a su gerente lo difícil que está trabajando.

Answer 2

En MSBuild, los objetivos deben especificar entradas y salidas, siempre que sea posible (para habilitar el cálculo de la dependencia). Si es necesario, utilice el atributo de Devoluciones para especificar un objetivo que devuelva elementos diferentes a los utilizados para el cálculo de la dependencia.

Los elementos de entrada y salida para un objetivo determinado se deben generar utilizando transformaciones de elementos (para transformaciones simples basadas en rutas) u otro objetivo (para transformaciones más sofisticadas).

Para MSBuild pre-4.x, para destinos que defina en a.archivo objetivos, considere usar el siguiente patrón que los consumidores puedan inyectar sus propios objetivos antes que los que está definiendo:

<PropertyGroup> 
    <MyTargetDependsOn> 
    Target1; 
    Target2; 
    SomeOtherTarget 
    </MyTargetDependsOn> 
</PropertyGroup> 
<Target 
    Name="MyTarget" 
    DependsOnTargets="$(MyTargetDependsOn)"> 

</Target> 

Esto permite a los consumidores para inyectar sus propios objetivos antes de que el destino especificado simplemente modificando el valor de la MyTargetsDependsOn propiedad:

<PropertyGroup> 
    <MyTargetDependsOn> 
    $(MyTargetDependsOn); 
    YetAnotherTarget 
    </MyTargetDependsOn> 
</PropertyGroup> 
<Target 
    Name="YetAnotherTarget"> 

</Target> 

En MSBuild 4.x, sólo tiene que utilizar los BeforeTargets y atributos AfterTargets.

Answer 3

Sólo un comentario sobre el segundo punto que se ha mencionado anteriormente:

Si un proyecto contiene un conjunto de subsistemas y cada subsistema tiene sus propios scripts de construcción, el fichero de construcción del proyecto debería simplemente llamar al compilar scripts de subsistemas.

Cada subsistema debe tener su propio archivo de compilación, pero ese archivo debe importar un archivo de compilación común. El archivo de creación común contendría objetivos tales como compilación, pruebas, etc. paquete

http://ant.apache.org/manual/Tasks/import.html

El subsistema de construir archivos son entonces muy simple, no contienen la duplicación y sólo contienen información que es específica para ese subsistema (por ejemplo compile.classpath).