如何处理 TF Build 2012 中的多个常见依赖项？

Question

我最近开始在 Gated Check-in 期间自定义我的构建活动，仅使用 MSBuild 来管理我的任务。它工作得比较好。 但问题是：任务工作流完全基于先前关于任务执行时间到优化并行性能的知识。以下是我的工作流程的恢复版本，以便您了解问题

• 两个主要目标：执行一些测试并验证数据库迁移
• 要执行测试，我必须构建解决方案、构建数据库项目并发布数据库
• 为了验证数据库迁移，我还需要构建和发布数据库（不能与将执行测试的数据库相同）并且需要做一些“额外的事情”。

为了优化我的工作流程，我想并行运行解决方案的构建、“额外的东西”和数据库的构建/发布，但我不想混合不必要的依赖项，比如数据库迁移等待解决方案的构建或测试执行等待“额外的东西”。

在 MSBuild 和 WWF4 中，我只知道如何通过在一轮中执行所有依赖项来并行化活动，然后执行另一组依赖项...

有没有更好的方法来做到这一点？我的意思是，定义工作流，以便自动解决和优化依赖关系。

P.S.：我使用的是 TFS 2012。

更新： 我已经进行了两次并行构建我的项目解决方案的测试，看看会发生什么。结果是一个 MSBuild 节点在尝试构建我的解决方案之前等待另一个节点完成，然后说它是最新的。例如：

<Project>
    <ItemGroup>
        <Project Include="MyProject.sln" />
        <Project Include="MyProject.sln" />
    </ItemGroup>

    <Target Name="Build">
        <MSBuild Projects="@(Project)" Targets="Build" BuildInParallel="true" />
    </Target>
</Project>
<!-- When I check the build log it says 
    1> Project is building MyProject.sln (2) ...
    1> Project is building MyProject.sln (2:2) ...
    2> Building with tools...
    2> ...
    2:2> Building with tools...
    2> ...
    2> ...
    2> ...
    2> Done building
    2:2> Target ... skipped because it was previously built successfully
    2:2> Done building
-->

这是一种理想的行为，但是当我尝试依靠它来构建构建工作流程时，我的项目同时构建了两次，这给了我很多错误。

Answer 1

您可能会受益于将所有集成测试转移到已部署的环境中而不是在构建期间执行它们。首先，正如您所发现的那样，构建服务器有点适合该任务，其次您正在等待构建队列。

理想情况下，您应该只在构建服务器上运行单元测试并延迟集成测试。我会使用发布管理工具在构建后自动部署我的应用程序，然后运行集成测试。我使用 Visual Studio 的 Release Management（适用于 2012），但 octopus deploy 也是一个很好的解决方案。

http://nakedalm.com/create-release-management-pipeline-professional-developers/