I currently manage a TFS 2018.2 TFS server for 100 users that have Visual Studio Enterprise. On our build and release resource limits tab we show that we have 103 release pipelines.
I am acquiring the management of another TFS 2018.3 server, but the users only have Visual Studio Professional. As such their release pipelines are limited to 1 pipeline.
I have read the page at: https://blogs.msdn.microsoft.com/tfssetup/2017/11/14/understanding-build-and-release-pipelines-visual-studio-team-servicesteam-foundation-server/
From that information I believe what I am reading is that this number only affects Releases running in the TFS Release pipeline, and not build running in the build pipeline. #1 : Did I interpret this correctly?
Second, we are considering upgrading our server to Azure DevOps Server 2019. On this page: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops-2019&tabs=browser
There is an important note stating as follows:
Starting with Azure DevOps Server 2019, you do not have to pay for self-hosted concurrent jobs in releases. You are only limited by the number of agents that you have.
Therefore, if we do upgrade to the on-premises version of TFS Server, we can run all of both builds and releases currcurrently for which we have agents installed. #2 : Can you confirm this is also correct?
I tested and confirm your interpretation for the documents in above links is correct.
With TFS, you only need pipelines for deploying releases; no pipelines are required for builds since unlimited concurrent builds are included with the TFS server license.
I tested on tfs2018 multiple build pipelines could run concurrently based on how many on-premise agents I have installed. But i can only run one release once a time.
Starting with Azure DevOps Server 2019, you do not have to pay for self-hosted concurrent jobs in releases. You are only limited by the number of agents that you have.
I also tested on vsts2109, both build and release pipeline can concurrently based on how many on-premise agents I installed.
Related
I am looking for how to publish a Jenkins build output to Azure Dev Ops for the purpose of deployment.
All of our code is on TFS 2015 and the build definitions are in Jenkins.
We will be migrating to Azure Dev ops completely, but for now I just want to manage the deployment through Dev Ops. I will script the agent on each of the hosts and move the files to their correct locations.
Looking at the Azure Cli - there Publish Pipeline Artifacts
I can't use a service connection to Jenkins because the server is behind a firewall. I need to be able to publish from Jenkins to Azure Dev Ops.
Any creative ways to do this?
for example, you could create a nuget package (or any other package) from jenkins build and push it to the artifacts feed you create in azure devops. Next is to create a release pipeline with a trigger for Azure Artifacts (with enabled continuous integration trigger) for the latest package version.
here is an example on how to publish nuget packages from jenkins.
EDIT
be aware of the size limitations of Azure Artifacts. As per today, only 2 GB are free of charge.
I have a question about forcing/permitting where the TFS Build Cleanup jobs get run. This is not a question of when they are run, but a question of how to direct TFS to run them on specific build server(s). First the background:
I manage a small farm of on-premise build/release servers, all connected to an on-premise TFS2017 Update 2 system, with agent 2.117.2 installed on the build/release servers. One of these build/release servers exists in a separate domain (our production domain) from our development domain, and purposely only has read access into the development domain.
Our builds, and development releases occur on the servers in the development domain, and those builds are directed to those build/release servers via build/release demands in the configurations. This all works well.
Its only been recently that we've had a release server in our production domain, and with that has come the realization that TFS is 'randomly' choosing an available server on which build cleanup jobs are to be run. This random allocation to an available build/release server is a problem.
While the cleanup jobs could run on any build/release server in the development domain without problem - they can not run on the release server in production as that server only has read access into the development domain by design. As a result, all triggered cleanup jobs on the production release server fail.
Is there a way to limit which execution agents the TFS Build Cleanup jobs are able to be triggered on? Providing R/W access to the prod release server is not a desirable workaround to this problem.
For on-prem TFS 2017 when I try to update all agents in the agent pools, the update does not happen. I see the same old agent version.
Build servers typically do not have internet connectivity.
Is internet connectivity a pre-requisite for updating on prem build agents?
I had to download the new agent for a machine where I have internet and then copied the files over to a new folder in the build machine and reconfigured the agent from this new folder. After this is done I had 2 agent services - 1 pointing to older folder and 1 pointing to new folder. The service pointing to old folder was started and the new service was in stopped state. Stopped the old service and started the new service.
Is the process different for updating agent version for on-prem TFS?
Even if you have Internet connection, the update may not work.
According to Daniel Steiner there are 2 kinds of agents:
Windows specific agents (version 1.x)
cross platform agents (version 2.x)
In TFS 2017 the Windows specific agents (version 1.x) are deprecated. Thus they won't be updated from the agent queues admin area. So you have to download the agent from tfs (or github) and install it yourself. After initial installation/configuration the agent updates via tfs should work again. It would have been cool if they automated that process or at least said what to do in tfs.
Unfortunately the official docu does not make the whole issue clear enough.
Yes you need internet connectivity for updating on prem build agents.
Each agent automatically updates itself when it runs a task that
requires a newer version of the agent. But if you want to manually
update some agents, right-click the pool, and then click Update all
agents.
All build agents within the selected pool will go offline temporarily and then come back online as soon as they are updated.
Which you have done is manually adding a newly version agent, not updating the agent. There are just two agents in your build server,so you had two agent services.
More details about update agent in on-premise TFS server, you could refer below tutorials:
Updating Your Team Foundation Build Agents
Upgrading TFS 2015 Build Agent
Trying to make my CI/CD work using TFS. Have to overcome some of this user role setup. Also not really getting my head around the terminology and the workflow (kinda different with how Jenkins works) and at the same time I have to figure the myriad of TFS versions(2010/2012/2013/2015/2017) and the online Visual Studio team services. I have to unlearn what I already know somehow, thus my basic questions:
What are agent queue? What are pools? (when i click create queue, it will ask me to create new pool)
What does "Download Agent" means? I thought this agent will be installed on the server side like a plugin that you install in Jenkins.
I think this might help clarify:
An agent pool defines the sharing boundary for all agents in that
pool. In TFS, pools are scoped across all of your Team Foundation
Server (TFS); so you can share an agent pool across team project
collections and team projects. In Team Services, agent pools are
scoped to the Team Services account; so you can share an agent pool
across team projects.
An agent queue provides access to an agent pool. When you create a
build or release definition, you specify which queue it uses. Queues
are scoped to your team project in TFS 2017 and in Team Services, so
you can only use them across build and release definitions within a
team project.
An agent in TFS / VSTS does work (like a build or a release). Microsoft offers agents they host if you are using VSTS. Alternatively, you can setup your own agents. For example, if you need to run your build on a particular machine because it has some needed items to do compilation or you're using TFS and can't use the hosted, you'd need to download the agent and configure it on a machine. You can have multiple agents on one machine. I'd recommend not installing an agent on the same machine as the TFS application tier if you're working with an on premise installation.
The official tutorial which involves a lot of aspects about Team Services and TFS. Most of the concepts is the same in /2013/2015/2017 and Team service. You just need pay attention to the support version under the topic such as below screenshot:
An agent queue provides access to an agent pool. When you create a
build or release definition, you specify which queue it uses. Queues
are scoped to your team project in TFS 2017 and in Team Services, so
you can only use them across build and release definitions within a
team project.
More details about agent queue and agent pool, you could refer this link: Agent pools and queues
each queue can use only one agent pool.
This is why when you click create queue, it will ask you to create new pool.
For TFS2015, you are using the private agent.
An agent that you set up and manage on your own to run build and
deployment jobs is a private agent. You can use private agents in Team
Services or Team Foundation Server (TFS). Private agents give you more
control to install dependent software needed for your builds and
deployments.
You could use the download agent to Deploy an agent on Windows. And one of the most commonly used scenes of the "Download Agent" is when you are installing multiple private agents on the same machine.
Is it possible to configure an on-premise TFS 2015 (Update 2) instance to make use of the hosted agent pool in a Visual Studio Team Services account?
All our builds / releases are currently done in-house, but to simplify the process of automated testing using clients and services hosted in Azure, we would like to move to VSTS-based agents (initially just for the release tasks, but possibly for build tasks later on).
The real desire here is to have our automated tests run outside our local network so our connection is not saturated with all the chatter of set-up / test run / tear-down against our cloud-hosted applications. These UI tests happen as part of our release process (using TFS Release Management).
I'm not 100% sure that configuring Releases to run on a hosted agent is the right approach to the problem, but it's what we're investigating for the time being anyway.
Hosted Pool currently works only with VSTS.
The only option for you at this point of time is to setup a VM with VSOAgent and configure it with TFS On-Prem. This will require your TFS to be exposed to internet (or just to the VM) so that the agent on Azure can configure itself.
Source - I am a Dev for the Hosted Pool Service.