I've recently started customizing my build activity during Gated Check-in using only MSBuild to manage my tasks. It is working relatively fine. But the problem is: the tasks workflow is entirely based in previous knowledge about tasks execution time to optime parallel performance. Below is a resumed version of my workflow so you can understand the problem
- Two main goals: execute some tests and validate database migration
- To execute tests, I have to build the solution, build database projects and publish the databases
- To validate database migration I also need to build and publish the databases (cannot be the same on which the tests will be executed) and need to do some "extra stuff".
To optimize my workflow, I would like to run in parallel the build of the solution, the "extra stuff" and the build/publish of the databases, but I don't want to mix unnecessary dependencies, like the database migration waiting for the build of the solution or the test execution waiting for the "extra stuff".
In MSBuild and WWF4 I only know how to parallelize the activities by executing all the dependencies in one round then execute another set of dependencies...
Is there a better way of doing this? I mean, defining the workflow so the dependencies are automatically resolved and optimized.
P.S.: I'm using TFS 2012.
UPDATE: I've made a test building my project solution twice in parallel to see what happens. Turns out one MSBuild node waits the other to finish before trying to build my solution and then says it's up-to-date. Ex.:
<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
-->
This is a desired behaviour, but when I try to rely on this to make my build workflow, my projects are built twice simultaneously, giving me lots of errors.
You would likely benefit from moving all of your integration tests to a deployed environment and not executing them during the build. First the build server is bit suited to that task, as you are finding, and second you are holding up the build queue.
Ideally you should only run unit tests on the build server and delay integration tests. I would use a release management tool to automatically deploy my application after a build and then run integration tests. I use Release Management for Visual Studio (works with 2012) but octopus deploy is also a good solution.
http://nakedalm.com/create-release-management-pipeline-professional-developers/