Team Build - развертывание нескольких конфигураций - PullRequest
Новая
       9

Team Build - развертывание нескольких конфигураций

0 голосов
/ 17 января 2010

У меня есть ночной сценарий, который должен создавать файлы отладки и выпуска zip, а затем загружать их через ftp на клиент.

Я всегда использовал AfterDropBuild для развертывания одной конфигурации, которая работает нормально, но сборка обеих конфигураций в одной сборке, похоже, не работает. Я надеялся, что AfterDropBuild будет выполняться дважды. Конечно, я могу кодировать задачи в AfterDropBuild для обработки обоих конфигов, но это не так.

Есть ли лучший способ? 

<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>

Спасибо

1 Ответ

0 голосов
/ 17 января 2010

Вы можете добавить столько конфигураций, сколько захотите, в SolutionsToBuild (например, мы создаем несколько отдельных библиотечных решений, а затем два разных приложения, которые построены из одного и того же исходного кода (одно решение), но построены из двух конфигураций с использованием #define для изменить выходной код)

Вы получаете вызов только один раз, когда сборка завершается, но этот обработчик может затем выполнить столько процессов / шагов, сколько необходимо для развертывания результатов (в нашем случае мы собираем два скомпилированных приложения плюс загрузку файлов ресурсов в 10 различных специфичные для клиента установщики, так что после нашей сборки есть 10 «шагов», каждый из которых производит еще один конечный результат).

Вы можете поместить команды, чтобы встроить каждый из этих окончательных результатов в свою собственную цель, так что действительно легко включить / исключить различные результаты из сборки, если вам нужно регулярно разбивать и изменять вещи - но есть вероятность, что после настройки Вам не нужно будет часто менять его в любом случае. Тогда единственный код «особого случая», который должен знать о том, что все эти варианты построены, будет целью пост-сборки, которая будет просто зависеть от любых целей, которые вам нужны. Так что все заканчивается довольно аккуратно.

...