> Multiple phases you add to a build definition run in parallel. Multiple phases you add to a release definition run in sequence. You cannot configure the order of dependencies between phases in this version of TFS.
This is not correct, they run in sequence, or I configured it wrong :(
I want to build on windows, mac and linux in parallel, but can't get it configured correctly. For now I need to use multiple builds.
⚠Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von Problemen docs.microsoft.com ➟ GitHub erforderlich.
Thank you for your feedback. I have passed this on to the product team for advice.
Support for running phases in parallel in release is still few months away (~5-6 months tentatively). On VSTS build supports running phases in parallel, for support in TFS @vijayma
Can you confirm my understanding of your setup?
If so, this is not expected, and we would like to follow up with you.
@vijayma
I can confirm this behaviour.
I have a build definition with 3 phases. I want 2 to run in parallel and the 3rd to wait for previous to succeed.
Phase 1 & Phase 2 have no Dependencies and are set to 'Even if a previous Phase has failed'.
3rd Phase has Phase 1 & 2 as Dependencies and set to 'Only when all previous phases have succeeded'
When I queue a build, they all run in sequence. Phase 1 & 2 do not run in parallel
+1. I also noticed the same behavior in Release using VSTS. It appears the Phases in Build will run in parallel, but Phases in Release will run in sequence, even if I put true in the custom condition
Thanks for pointing this out. We went and checked again in 2018.2, and indeed found that the ability to run phases in parallel did not exist in 2018.2. That feature missed 2018.2 by a very narrow margin. Sorry about the confusion. We are fixing the doc to clarify this.
To clarify, I'm seeing the behaviour of build phases running in sequence and not in parallel on vsts and not tfs.
@oneillci, I was responding to the original question by @biohazard999. Regarding your issue in VSTS, to run both the jobs in parallel, you need a concurrency of 2 jobs. My guess is that you do not. You can check the concurrency limits you have by going to Project settings -> Build and Release -> Concurrency. You can purchase additional concurrency if you desire. Another possibility is that you do not have "Build with multiple queues" preview feature enabled. You can check that in your user profile -> Preview features -> Account features.
@vijayma, if I'm looking at the correct setting, I do have enough concurrent jobs permitted:

When running my build, my agent phases are not running in parallel. In this example, phase 1 and 2 do not have any dependencies, but phase 3 depends on both 1 & 2. All phases are set to run on the same agent queue. Do I need to have multiple agents running in that queue or does this look like I'm doing something else wrong?

I've tried adding more agents to my pool and now have them running parallel :) Have submitted some content feedback on that page as this was no clear from the existing documentation.
I am on TFS 2018.3 and this still seems to be a problem. I have a build definition with two phases and they do not run in parallel. Is there any update on this?
I can also verify this. We are running TFS 2018.3 in production with a new install on the test server. Even in BUILDS (nevermind the release pipeline), phases not only run serially, the dependencies setting on the phase properties isn't even there. It is there in Azure DevOps. Not in an on-premises installation. There does not seem to be any means of using parallelism usefully in an on-premises installation of TFS 2018.3.....
Also verified. Running TFS 2018.3 and cannot find any way to run Phases in parallel. This is a serious issue for us as it is making our Releases run extraordinarily long. Please advise when this is going to be resolved for on-prem or a workaround?
Most helpful comment
Also verified. Running TFS 2018.3 and cannot find any way to run Phases in parallel. This is a serious issue for us as it is making our Releases run extraordinarily long. Please advise when this is going to be resolved for on-prem or a workaround?