I am running into problems getting my build servers to run releases in parallel.
I just recently created my second build and test server. Both servers correctly run builds in parallel. And each of my builds triggers a release upon successful completion. However, only one server at a time will run a release.
I have verified that both servers are configured correctly because if I take down one server the other one starts running the releases correctly. However, when both are stood up together only one of them will run releases.
Is there a setting in TFS that does not allow multiple separate release definitions to run in parallel on different machines?
A TFS concurrent pipeline gives you the ability to run a single release at a time in a team project collection.
You can keep hundreds or even thousands of release definitions in your collection. But, to run more than one release at a time, you need additional concurrent pipelines.
One free concurrent pipeline is included with every collection in a
Team Foundation server. Every Visual Studio Enterprise subscriber
in a Team Foundation server contributes one additional concurrent
pipeline. You can buy additional private pipelines from the Visual
Studio Marketplace.
Purchase additional concurrent pipelines
If you need to run more concurrent releases, you can buy additional private pipelines from the Visual Studio marketplace. Since there is no way to directly purchase concurrent pipelines from Marketplace for a TFS instance at present, you must first buy concurrent pipelines for a VSTS account. After you buy the private pipelines for a VSTS account, you enter the number of purchased concurrent pipelines manually on the resource limits page described below.
http://{your_server}:8080/tfs/DefaultCollection/_admin/_buildQueue?_a=resourceLimits
Note: above is for TFS2017/2018.
If you are using TFS2015, take a look at this question: Do I need concurrent pipelines to use release management in versions before TFS 2017?
More details suggest you go through the official link in MSDN: Concurrent release pipelines in Team Foundation Server
The system seems to still be based on the honor code.
Through the link PatrickLu-MSFT gave I was able to change the number to anything I wanted, even though I did not actually purchase any additional licenses.
After resetting the additional licenses back to zero, I also found this link:
http://{your_server}:8080/tfs/_admin/_licenses
Again, it seemed to be based on the honor code here as well because I was able to add users with subscriptions to less than Enterprise to the VS Enterprise group.
However, when all my exploring was done, I was able to use that final link to enter the people who do have Enterprise subscriptions and that changed my overall license count so I was able to run releases in parallel.
Related
Im kinda new to Devops
i want to create a basic release pipeline, that instead of running on 1 or several servers- would run individually on each developer's machine, and ONLY WHEN THEY CHOOSE TO RUN IT.
NOT scheduled, and NOT by one person who decides to run it for all developers at a certain time.
that means each developer would have an agent on their developing machine.
so i figured, each developer would have access to their own private area on TFS (Azure Devops)
in which they would (ONLY!!) have access to their own Release pipelines. (several pipelines because there are several environments).
Dose that make sense? is my need common? any other recommended approaches for this need?
Thank You
Seems strange asking this on SO but that's what MS want us to do so here goes...
I'm looking at setting up an on-premise Azure DevOps 2019 server, but as usual the licensing and costs aren't very transparent.
Our dev team are likely to be getting Visual Studio Pro subscriptions, which I believe comes with a DevOps server license and CALs. What happens if we stop these subscriptions - does it mean we can no longer use our on-premise DevOps server?
I'm not very clear on what "extras" we may need to pay for (extensions, pipelines), and I don't want to be hit by any surprises. The essential requirements are:
Be able to trigger a build on check-in. I can't tell if this is a built-in feature or requires some kind of extension and/or pipeline (and if so free or not?)
Use build tasks to create NuGet packages and host these on the in-house server. Again, does this require any paid extensions or pipelines?
There should be no limits on monthly build time (unlike VSTS which I believe is 240 minutes)
To my best understanding:
You can run Azure DevOps Server 2019 with at least one Visual Studio Professional or Enterprise license.
The features available to each user are based on the licence assigned to the user: Stakeholders (no license) get the very basics, Basic access (Professional) gives you most of the features, Enterprise gives you all the features.
The most notable differences between Basic and Enterprise are:
View Releases and Manage Approvals
Artifacts Microsoft published
Azure DevOps Extensions
However, per this annoucement, Artifacts are now included in the Basic/professional license.
So with only professional licenses you should be good for triggering builds, publishing and using nuget-packages via Artifact feeds. I'd think that installing extensions might require Enterprise user and haven't tested "View Releases and Manage Approvals" without Enterprise license yet. That seems to have changed from older TFS we've been using, in which Basic users were able to create and view releases.
So would recommend getting at least one Enterprise license, in any case.
one and two are free, third one is free with self hosted agent and 1800 minutes with hosted agent, if you are an opensource project you have lots of free compute time (dont think this applies to Azure Devops server though).
Build and release pipelines are included in Azure Devops Server 2019. https://learn.microsoft.com/en-us/azure/devops/server/release-notes/azuredevops2019?view=azure-devops#changes-to-artifacts-and-release-management-deployment-pipeline-licensing
I have 10 build agents configured in two servers under one agent pool. Whenever the first four agents are used, the build requested is in the queue on the first four agents, but there are another six agents which are available and the builds are not queued to those agents.
It's been almost six months and agent 10 has not even once handled a build. Other agents from 5 to 10 are hardly used. Why is there this phenomenon? How can we handle this by using all the agents fairly?
TFS will auto select the available build agent in the pool when running the build. It's more like a conditional random choice. It's not able to prioritize the build agent for now. There has also been a related uservoice as below:
TFS 2015 build vNext agent prioritization
As a workaround you could specify a build agent in vNext build.
You can add a User Capability to that specific build agent. Then in the build definition you just need put in that capability as a demand (General tab).
It seems like the builds are queued on the 'oldest' agents first. So if agent 10 is the last agent you created, it will only be used if the first 9 are in use, assuming they all have the same capabilities.
It does not appear to be a random selection of agents, but based on the order of creation of agents. Ironically that means that if you add a new powerful build server, those agents will be at the bottom of the queue.
The user voice suggestion in PatrickLu-MSFT's answer is to allow the agent to be prioritized.
The workaround at this moment seems to be to remove all (or some) agents and re-create them in the order you want them to be used. Which still means the last agent will be used less, but at least you can influence the distribution of the agents a bit.
We are running into this issue as well. We have six build servers with three agents each and builds are not distributed fairly. I also do not want to assign an agent per definition, but I guess we are going to have to puzzle with it.
As per TFS documentation (Documentation), when the "Batch changes" option is selected, the maximum number of concurrent builds can also be specified, but I can not find any documentation on how to limit the maximum number of concurrent builds. Any help, please?
First just as the doc said, the batch changes is used for reducing the number of builds you are running.
If you select this option, when a build is running, the system waits
until the build is completed and then queues another build of all
changes that have not yet been built.
However you can't run multiple solution builds in parallel in TFS 2015, it's only able to run multiple configurations and platforms in parallel. Some related topic:
Parallel build in TFS 2015?
TFS 2015 v.Next build: Parallel solution builds?
So the concurrent builds should be running builds on multiple build agents the same time. You can't run concurrent builds on a single agent. It looks like a lack of content, I will submit this through internal channels, once updated will let you know. You could also submit a feedback on MS connect page or GITHub Issues page. Through this you may get a faster response.
My company has a bunch of different builds and half a dozen different build agents, and I need to update some software for one of the builds. I don't want to break any other builds that are using said agent. I would like to get a list of all builds that use said agent so that I can validate them after my software updates on the agent. I would prefer not to individually review each build, as there are dozens, if not hundreds of them. Is there some way to get this information quickly? Either from the agent, or from TFS somehow?
By default, builds are tied to controllers, not agents and could therefore run on any of the agents bound to the controller. Unless as suggested by Daniel Mann, you have your builds tagged to specific agents you won't be able to get that level of detail. Without tagging, your report would be limited to a list of machines that each build could possibly run on.
What I do in this situation is to have a separate, private build controller for build software testing. Upgrade the software on this and then queue test builds for the affected definitions, changing the controller to your test controller in the Queue Build parameters. Once you've verified that your changes won't break the builds you can then schedule downtime to upgrade the production agent machines.