Team Build - déploiement de plusieurs configurations

Question

J'ai un script tous les soirs qui devrait générer des fichiers zip Debug et Release, puis les télécharger via ftp sur le client. J'ai toujours utilisé AfterDropBuild pour le déploiement d'une seule configuration - qui fonctionne bien - mais la construction des deux config dans une seule construction ne semble pas fonctionner. J'espérais que AfterDropBuild s'exécuterait deux fois. Je peux bien sûr coder les tâches dans AfterDropBuild pour gérer les deux configs mais cela ne me semble pas correct.

Y a-t-il un meilleur moyen?

<Target Name="AfterDropBuild"> 
    <CreateProperty Value="$(DropLocation)\ToClient"> 
     <Output PropertyName="DeploymentFolder" TaskParameter="Value" /> 
    </CreateProperty> 
    <GetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)"> 
     <Output TaskParameter="BuildNumber" PropertyName="BuildNumber"></Output> 
    </GetBuildProperties> 
    <CreateProperty Value="%(ConfigurationToBuild.FlavorToBuild)"> 
     <Output PropertyName="ConfigFlavor" TaskParameter="Value" /> 
    </CreateProperty> 

    <MakeDir Directories="$(DeploymentFolder)" /> 

    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
       BuildUri="$(BuildUri)" Name="ZipSite" 
       Message="Zipping Site"> 
     <Output TaskParameter="Id" PropertyName="ZipStepID" /> 
    </BuildStep> 
    <!-- get a list of all the files in the published web sites --> 
    <CreateItem Include="$(OutDir)_PublishedWebSites\Site.Web\**\*.*" > 
     <Output TaskParameter="Include" ItemName="FilesToZip"/> 
    </CreateItem> 
    <CreateItem Include="$(OutDir)\Site.msi" > 
     <Output TaskParameter="Include" ItemName="FilesToZip"/> 
    </CreateItem> 

    <!-- zip the deployment files --> 
    <Zip Files="@(FilesToZip)" 
     ZipFileName="$(DeploymentFolder)\Site_$(BuildNumber)_$(ConfigFlavor).zip" 
     WorkingDirectory="$(OutDir)_PublishedWebSites\Site.Web" /> 

    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
       BuildUri="$(BuildUri)" Id="$(ZipStepId)" Status="Succeeded" /> 

    <!-- upload the zip --> 
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
       BuildUri="$(BuildUri)" Name="UploadZip" 
       Message="Uploading Zip to Client"> 
     <Output TaskParameter="Id" PropertyName="ZipUploadID" /> 
    </BuildStep> 

    <CreateItem Include="$(DeploymentFolder)\*.zip" > 
     <Output TaskParameter="Include" ItemName="FilesToUpload" /> 
    </CreateItem> 

    <FtpUpload 
     RemoteUri="ftp://ftp.blahblah.com/" 
     LocalFiles="@(FilesToUpload)" 
     RemoteFiles="@(FilesToUpload->'%(RecursiveDir)%(Filename)%(Extension)')" 
     UserName="user" 
     Password="password" 
     /> 
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
      BuildUri="$(BuildUri)" Id="$(ZipUploadID)" Status="Succeeded" /> 
    </Target> 

Merci

Answer 1

Vous pouvez ajouter autant de configurations que vous le souhaitez à l'SolutionsToBuild (par exemple, nous construisons plusieurs solutions de bibliothèque séparée, puis deux applications différentes qui sont construits à partir du même code source (une solution) mais construit à partir de deux configurations en utilisant un #define pour modifier le code de sortie)

Vous n'êtes appelé qu'une seule fois lorsque la génération est terminée, mais ce gestionnaire peut alors exécuter autant de processus/étapes que nécessaire pour déployer les résultats (dans notre cas, nous construisons les deux applications compilées plus une charge de fichiers de ressources dans 10 différents clients c installateurs, donc il y a 10 "étapes" à notre post-construction, chacun produisant une autre sortie finale).

Vous pouvez placer les commandes pour construire chacun de ces résultats finaux dans sa propre cible, donc il est vraiment facile d'inclure/exclure différents résultats de la construction si vous devez couper et changer les choses régulièrement - mais il est probable vous n'aurez pas besoin de le changer souvent de toute façon. Ensuite, le seul code «cas particulier» qui doit savoir que toutes ces variantes sont construites sera la cible de post-construction, qui dépendra simplement des cibles dont vous avez besoin. Donc, ça finit bien rangé.