tfs - TeamBuilds modulares

msbuild build-automation (2)

su mejor opción es colocar las cosas comunes en la máquina de compilación en $ (MSBuildExtensionsPath) que se resuelve en C: / Program Files / MSBuild

No me gusta la idea de tomar una dependencia en ubicaciones "mágicas". Terminas necesitando un segundo proceso de implementación + QA solo para mantener tus scripts de compilación sincronizados ...

Solo los elementos en la carpeta de compilación (bajo TeamBuildTypes) son recuperados automáticamente por Team Build.

Un poco cojo, ciertamente, pero no he encontrado que sea una limitación importante en la práctica. Aquí hay una vista simplificada de mi carpeta TeamBuild:

Common.targets es importado por todos los archivos * .csproj (etc.). Importa todas mis tareas de terceros, inicializa varias propiedades / elementos globales y configura rutas de referencia.

TFSBuild.proj importa Common.targets, luego TFSBuild.proj, luego uno de los archivos de configuración acondicionando en $ (BuildDefinition). De esta forma, los más específicos siempre anulan tareas / propiedades / etc de archivos menos específicos según sea necesario. Aún así, este archivo corto es el único lugar donde me siento limitado: sería mucho más fácil asignar nombres de compilación a nombres de archivo mediante programación, pero MSBuild no me permitirá hacer que las importaciones [declarativas] dependan de las propiedades establecidas en objetivos [runtime] como .

Los archivos TFSBuild.Config * .targets solo establecen propiedades, en su mayor parte; no hay trabajo "real" Estos abarcan las propiedades de Team Build que quiero parametrizar, además de otras que controlan cómo funcionarán mis objetivos personalizados (implementados en otro lugar).

TFSBuild.Common.targets es el archivo más largo en un orden de magnitud. Aquí configuro todas las propiedades de Team Build con buenos valores predeterminados, anulo los objetivos como AfterDropBuild, y defino muchos de mis propios objetivos personalizados que se ejecutan condicionalmente según lo establecido en los archivos de Config *.

Nota: obviamente tengo la opción de descarga recursiva activada , pero no es estrictamente requerida. Separar las dependencias de construcción en subcarpetas es más por estética que nada.

Tengo 3 TFS Builds (2 Dev y 1 Cert).

Me gustaría modularizar las compilaciones para no tener que editar 3 archivos cada vez que realizo un cambio en los elementos comunes.

El problema que tengo es que solo los elementos en la carpeta de compilación (bajo TeamBuildTypes) son recuperados automáticamente por Team Build. Puedo poner el código en mi proceso de compilación para obtener otros archivos, pero para entonces ya es demasiado tarde.

Aquí está el escenario que tengo. Hago una ubicación "común" para tareas comunes. Luego fui y realicé cambios en ese archivo. Debido a que el archivo no se carga hasta que mi proceso de compilación ordena que se descargue, se recupera demasiado tarde (la importación ya se ha realizado y el proceso de MSBuild ha construido los objetivos de compilación en la memoria).

Pensé en agregarlo al espacio de trabajo de la construcción, pero luego lo recuperaré en el objetivo Obtener fuentes (que también es demasiado tarde).

No veo una solución que no me permita duplicar el archivo o no usar el control de código fuente ...

¿Algunas ideas?

No hay una solución "ideal" para este problema en Team Build 2008, su mejor opción es colocar los elementos comunes en la máquina de compilación en $(MSBuildExtensionsPath) que se resuelve en C:/Program Files/MSBuild y luego hacer referencia a ellos desde allí.

Si sus configuraciones de construcción son muy similares, podría:

Apunte todas sus definiciones de compilación a una única carpeta de configuración.
Coloque la lógica de compilación común en TFSBuild.proj .
En la parte inferior de TFSBuild.proj, agregue <Import Project="TFSBuild.$(BuildDefinitionName).proj" /> .
Agregue la configuración que varía entre las definiciones de compilación en TFSBuild. <BuildDefinitionName>.proj .