I am testing a TFS 2015 to TFS 2018 upgrade. My environment includes one database server, one TFS app server, and one TFS build server. I was able to upgrade the app tier without any issues. It's been awhile since I've done this, but I assume I just run the TFS upgrade installer again on the build server and it will give me the option to update the build agent? I didn't see anything for it when I ran the upgrade on the app server.
Related
I have a TFS server on a remote machine, and succesfully installed a build agent on my own machine. The connection between these works as intended:
The agent is online, and running succesfully. However, when I try to queue a build, I get this error:
I think the solution lies in this text:
No agent found in pool Default which satisfies the specified demands:
msbuild
visualstudio
DotNetFramework
Agent.Version -gtVersion 1.98.1
Since I have MSBuild, VS2017 and .Net installed on my machine, I think it's the Agent.Version that's causing problems. But how do I check what version of the agent I have running? I followed this guide to installing the build agent. And where can I find other versions of the build agent online? The MS site doesn't seem to offer download options for older/newer versions of the build agent.
If you installed the agent according your link so the version should be fine (because you downloaded the agent from your TFS).
Go to Agent Pools page, then check the agent's Capabilities.
Look after the the version of MSBuild/VS/.Net, maybe on the agent computer the right version not installed.
Another option - the agent didn't recognize the installed stuff so you can add it to the agent's capabilities manually by click on "Add capability":
I had a similar issue after upgrading Azure DevOps On Premise from 2019 RC2 to 2019 Release. After the upgrade I had to download the new Build Agent from the Azure server and install the new version on my build agents. After upgrading the build agents they began reporting the correct capabilities.
The requirements on the following page state that you need to install Visual Studio with Xamarin on your local TFS server to setup Xamarin CI builds:
https://developer.xamarin.com/guides/cross-platform/ci/intro_to_ci/
topography of the CI
This is a real pain. We have lots of developers that rely on our local TFS server, most of whom don't do any Xamarin development. As such, any changes are heavily scrutinized. This often leads to us not installing the latest VS/Xamarin releases, as it's considered too risky for this vital bit of infrastructure.
We could have a Windows build machine with VS and Xamarin installed, that is connected to a Mac build machine. We'd be free to update the Windows and Mac build machines regularly, without the fear of compromising the TFS server. Is this possible? If not, why not?
Thanks in advance.
That diagram can't be right. There is no reason why you'd need VS or Xamarin installed on your TFS app tier.
I think it's showing a simplified configuration where the Windows build agent is installed alongside the app tier. That is a supported setup but is never, ever recommended by anyone, for exactly the reasons why you don't want to do it.
The diagram is simplified. You don't need to install anything on your TFS server. What you do instead is to install a Build Agent on a separate machine or virtual machine.
The installation details for the TFS 2017 / VSTS build agent v2 can be found in the official visual studio documentation.
The procedure is similar for both TFS and VSTS, where you generate an access token in TFS/VSTS, then simply enter the url for the TFS/VSTS instance when running the build agent install script, along with the access token.
There are build agents for Windows, Linux and macOS, so it is up to you how you configure how iOS builds are made.
After cloning a 2010 TFS server, upgrading the clone's OS to 2012R2, upgrading SQL Server to 2012 SP2 (11.0.5343), uninstalling TFS 2010, and upgrading to TFS 2013 with update 5, we are running into issues starting the Build Service on the clone.
I've removed the agents and build controllers referencing the other original server through Manage Build Controllers, in Visual Studio 2013.
I've tried to use the TFS 2013 upgrade wizard and it fails when attempting to start the build service so I tried to unconfigure: "tfsconfig.exe setup /uninstall:TeamBuild" and reconfigure through the TFS 2013 upgrade wizard but it yielded the same result.
The TFS database server, Build Server, controller, and agent are located on the same box
For measure, I've even deleted the agents, controllers, and Unregistered and Registered the Build Service in the Team Foundation Server Administration Console as both the batch account used on the original server but that failed so to rule out authentication, I used my domain account (I'm a Local Admin, SQL Server Admin, and TFS Admin) but still had the same result with both accounts.
The Windows event log states “Service cannot be started. The handle is invalid”.
I'm not sure what else could be missed does anyone have any pointers?
There were over 100 Microsoft patches/updates applied over the weekend and the issue went away. Microsoft confirmed that the issue was related to the OS, not the TFS configuration or installation/upgrade.
Thanks for all your suggestions. Hopefully this will help someone else out if they are in the same situation and spinning wheels to find the answer. Keep your systems as up to date as possible!
Try to remove build service by going to Team Foundation Server Administration Console, select server name, and click Remove Feature, to remove build service feature, then re-configure it.
I have TFS 2013 Update 3 installed on a machine and I'm trying to configure the TFS Build service on another machine on the same domain. The registration of the build service completes successfully but the service, controller, and build agents go into an endless start/stop/restart loop. The event viewer on the build machine gives the following error in the Build Services Operational log:
Build machine 'x' lost connectivity to message queue tfsmq://buildservicehost-18/.
Reason: TF30063: You are not authorized to access http://tfs2013:8080/tfs/defaultcollection.
Things I have tried:
Both NetworkService account and a domain account for the build configuration
Unregistering/re-registering the build service
Uninstalling TFS on build machine and reinstalling
Creating a fresh server 2012 install, installing TFS build component on it
The domain account I tried to use was in the build service account group for the collection and I've even tried putting it in the admin group. I also tried running it as my own domain account which is a tfs admin and domain admin account. All with the same results. The fact that this occurred on 2 different machines, one with a completely fresh everything install leads me to believe the problem is on the TFS application tier itself but I have no idea where to go from here. Visual studio is able to connect to TFS just fine for all users.
It sounds like you have a TFS 2012 server that you are trying to connect a TFS 2013 build agent to. This is not a supported configuration.
It is recommended that your build Agents version of TFS matched the version on the server. This does not mean that you can't build with any version of MSBuild or VS that you want on that agent. That's configuration.
I ended up resolving this by doing the following:
Detach Collection
Backup Collection as a precaution
Uninstall TFS 2013 from the App Tier (which is also the Data Tier)
Re-install TFS 2013 and configure it for single server like it was without creating a collection
Attach the existing collection
Uninstall TFS on the build server
Re-install TFS on the build server and configure the service, controller, and agents.
This worked fine and didn't cause me to lose anything. I still don't understand why I was having problems in the first place but my only guess is that it was some type of remnant from doing a migration based upgrade from TFS 2010.
My team uses Visual Studio Online ("VSO") to manage our ALM.
We already have a push-button build-process in place to build code from our local Git repo (remotely) and deploy it to a Microsoft Azure Website on Azure.
In addition to this we want a local, development-testing environment built and deployed with a push of a button.
What is the best way to integrate an automated, on-premises development-testing deployment into our development pipeline from within VSO's ALM ecosystem?
[We do also own TFS 2012 -- is there a way to leverage it from VSO to drive an on-premises build deployment from our VSO git repo?]
To deploy builds on-premise, I installed an on-premise build server and used it as the default build controller in my build definition.
When installing the build server select your Visual Studio Online url to point the build server to your team project collection.
I used the instructions here
http://myalmblog.com/2014/04/configuring-on-premises-build-server-for-visual-studio-online/
(normal issues when installing a build server remember to copy over your MSbuild folder from a machine with Visual Studio already installed etc...)
I know it's been a while since the question was asked, but this guy did it with an extension to be added to your VSTS account to deploy directly to an on-premise IIS. I'm going to check this solution today but I'm pretty sure it will work.
https://blogs.msdn.microsoft.com/monub/2016/01/20/visual-studio-team-services-release-management-iis-web-deployment-vnext/
UPDATE
Better yet, MSDN released a complete doc for deploying an asp.net app on IIS
https://www.visualstudio.com/en-us/docs/release/examples/other-servers/net-to-vm