I would like to upload on my TFS 2015 some of the build tasks that are available here https://github.com/Microsoft/vso-agent-tasks.
I do have a problem with certain task as they do require a minimum agent version of 1.89.0. My build agents are 1.83.2 version.
Now, the question is, how do I update my agents for a given pool? If I do right click the agent pool on my TFS and choose update all agents option, nothing happens. I suppose because the latest version of my agent available on TFS is the 1.83.2.
Where can I find the latest version of it and how do I update it?
Note I'm working on premises TFS 2015 and not VSO.
Thanks
If you right-click the agent pool and choose "Update all agents", it will upgrade the agents to the version of the on-premise TFS server. For instance, if you initially installed some RC, and upgraded the server to RTM later, some agents might have lower version. Otherwise, as you mentioned, nothing will happen because all agents are up to date.
VSO has a different release model and updates/fixes to its agents are continuously delivered. That's why the version is constantly growing.
Technically it might be possible to grab the source code of the latest VSO agent tasks, and push it to the on-premise version of TFS 2015. However, it is considered an anti-pattern, and the behavior is undocumented and unsupported.
Let me quote build vNext developers from this discussion (see the bottom of the thread):
That is not a supported option. It is very likely that the agent we
have in VSO will not work with the on-prem server. You must use the
version of the agent that ships with your server.
And:
The behavior is undefined/untested. It may work, may not. The design
is for agents to get pulled forward via an auto update process
downloaded from your service. The auto update process may alter
configs/layout on disk, whatever. That future agent might call REST
apis that don't exist, etc... The primary focus for agents is on
forward compat so they can lazily get upgraded (via task minimum agent
demand, on restart or eventually a scheduled job).
Same answer as #Yan, but putting this here because the following error came from nowhere - so I think Microsoft updated the minimum requirements this week.
No agent found in pool Default which satisfies the specified demands:
msbuild
visualstudio
Agent.Version -gtVersion 1.95.0
For your own hosted agent just right click on the queue, or click the ... icon.
I had to restart the agent service after a few minutes as it didn't seem to want to by itself. Give it a chance to update properly before doing this.
Related
We are looking to carry out the following TFS upgrades in our Production environment:
Upgrade TFS 2010 to TFS 2013.5
Upgrade TFS 2013.5 to TFS 2019
To support both migrations, we have a Windows Server 2019 Standard edition to host the Application Tier. The Data Tier is to be installed on a dedicated SQL box.
The Microsoft website however lists Windows Server 2012 (Essentials, Standard, Datacenter) as the latest server operating system edition required for TFS 2013.
My question therefore is, can we still perform this planned upgrade to TFS 2013 on a newer edition of Windows Server, in our case Windows Server 2019 Standard edition?
I agree with Daniel, please follow the documentation exactly.
Since you can upgrade from TFS 2010 --> TFS 2012.3 --> TFS 2019, or from TFS 2010 --> TFS 2013.5 --> TFS 2019, you could consider trying to upgrade from TFS 2010 to TFS 2012.3 or TFS 2013.5 on the same Windows Server 2008 R2 Enterprise server, and then migrate to Windows Server 2019 Standard edition when upgrade to DevOps Server 2019.1.1(TFS 2019.1.1).
"Supported" means "tested and known to work". Later OS versions haven't been tested and may not work, or TFS may not even install in the first place.
I've done dozens of TFS upgrades in my day. My suggestion is to follow the documentation provided by Microsoft exactly. If an OS isn't listed as a supported OS, then don't use that OS.
So after much to-ing and fro-ing and numerous debates and suggestions from various sources on Stackoverflow, in the end this is how I managed to successfully complete my migration upgrade from TFS 2010 to Azure DevOps Server (TFS) 2019.1
There are however 5 very important points I wish to emphasise:
This was a complete migration upgrade (not an In-place upgrade) and so each move to a later TFS version was done using new/replacement hardware.
Both upgrades were done, based on the excellent YouTube tutorial by Mohamed Radwan which can be found here and relies heavily on the TFSBackup and TFSRestore utilities, both of which have shipped with all versions of TFS, I believe since the 2012 edition.
I only migrated the TfsConfiguration database and our Project database.
There was no migration of SharePoint.
There was no migration of Reporting Services.
We had no scheduled backups set up in the TFS 2010 Admin console.
TFS 2010 to TFS 2013 - Some Useful Points to Note
The backup of my TFS 2010 databases were executed from the Tools directory of the TFS 2013 instance (once installed), on the new dedicated hardware for my app tier.
Following a successful database restore using the TFSRestore utility, there are generally three key tasks required which use the TFSConfig tool to ensure data integrity between the two TFS instances aren't compromised or corrupted. These are the PrepareClone, ChangeServerID and RemapDB tasks executed in this same order.
The PrepareClone task failed when executed and after days of trying to troubleshoot the issue, I gave up in the end due mainly to the fact that the PrepareClone command removes information about scheduled backups, SharePoint, and Reporting resources from an Azure DevOps Server deployment and is used in two circumstances:
When you move a deployment to new hardware but want to keep using the old deployment.
When you clone an Azure DevOps Server deployment.
We didn't have any scheduled backups, SharePoint or Reporting Services included within the scope of our migration and were certainly not planning to keep using the old deployment long-term, except for a few days of validation and testing of the migration upgrade. As such, I ignored the error.
I was also counting on the fact that if the ChangeServerID command run successfully, this would ensure that the two instances were now discrete anyway, having been assigned unique GUIDs. Fortunately, the ChangeServerID task succeeded.
I also then executed the RemapDB command but in truth this wasn't even required as the ChangeServerID command had already completed the remapping task.
From this point on, the migration went like a dream and there was absolutely no issues encountered. Another key point to add, the backup of our TFS 2010 instance was done only after I'd ensured there was no user logged onto the system and following the backup, I took the 2010 instance completely offline.
TFS 2013 to Azure DevOps Server (TFS) 2019.1 - Some Useful Points to Note
Again using the TFSBackup and TFSRestore utilities (this time from the Azure DevOps Server 2019.1 Tools directory) and pretty much repeating the steps for the previous migration upgrade, I managed to get us onto our target 2019 instance without single hitch.
Even better, with Azure DevOps 2019, the TFSConfig PrepareClone, ChangeServerID and RemapDB tasks have been incorporated into the app tier configuration wizard, meaning you're not required to manually run them from the commandline. The tool takes care of it for you in its entirety, which is excellent!!
The new Pre-Production Upgrade option enabled me to simulate and somehow perform a dry-run of the final upgrade, another excellent feature incorporated into the Server Configuration Wizard for Azure DevOps Server 2019.1
My Concluding Remarks
Judging by how easy and simple it was to use, its heavy use of automation and clearly being far less likely to result in any disaster, I am rather surprised the TFSBackup and TFSRestore tools aren't recommended as perhaps the current best migration options, subject of course to the type of migration targeted.
I have done TFS upgrades in the past which were based on the older process of quiescing the project collection, detaching and re-attaching the database(s) to the target instance, etc, etc and must admit there's hardly any chance I'd be going back to that in future if I can help it, as the TFSBackup and TFSRestore tools are a much, much better, safer and reliable option in my view.
Hopefully, this feedback will help the next person who may embark on a similar journey to upgrade TFS from the 2010 edition to a later version.
I recently upgraded from Team Foundation Server 2017 to Team Foundation Server 2018. I have a couple of questions about the build portion of the install. Our current TFS build agents live on a different server than the TFS Web application.
I believe in previous upgrades and installs there was an option on the install media to just install the build portion of TFS.
Do I have to do any type of upgrade on the build server or just update all of the agents from the web application as seen in this image 1?
Although my upgrade was from TFS 2017 to TFS 2018 the build server has an administration console that shows it's version as 2015 (see image 2). Do I need to uninstall this 2015 application?
Image 1
Image 2
There are two flavors of Build agents with TFS ever since 2015.
"Team Build"/"XAML Build"
This is the Controller+Agent based infrastructure that has been around since 2010 and which has been deprecated with TFS 2017. The agents that are supported are the 2010 (on XP and framework 4) and 2015 agents. There is an unsupported 2017 version of the XAML agent which is purely meant for single machine installations where the TFS application Tier and the Build agent are running on the same server.
2015 is the preferred version to be on for as long as you still need these. You should be planning to remove your dependency on these agents as soon as possible.
*2018u2** reintroduce the XAML agent, purely for clients who're too heavily invested in the XAML infrastructure to upgrade directly to the new build system. If you're one of these I sincerely hope you have a plan in place to break this dependency. This reintroduced agent comes pre-deprecated and will be removed again in a future version.
VSO/VSTS/vNext/2015 agents
These have had many names, but are essentially the new agents that shipped first with 2015. There are two versions of these 1.x and 2.x. While the new agents auto-upgrade, they only auto-upgrade to highest available build of their major version. To upgrade from 1.x to 2.x you will need to uninstall the old agent and install the new one.
As with the XAML builds, the 1.x agent is now considered deprecated and if you're still relying on these you should plan to upgrade to 2.x as soon as possible.
Concluding
If you're still using XAML builds, you should be using the Team Foundation Server 2015 Build Agent+Controller. And plan to move away from these. This will require re-authoring the build process to the new build+release infrastructure
If you're still using the 1.x VSTS build agents, you should be upgraded to the highest version of those. And plan to move away from these by uninstalling the 1.x agent and installing the 2.x agent that matches your TFS version.
If you're using the 2.x VSTS build agents, you can upgrade them from the TFS web based admin console. These are the preferred agents for both Build and Release.
The agents should auto-update.
That's XAML build. If you're not using XAML build, you can ignore it or even uninstall it entirely.
I am trying to update the build agent (TFS 2017) from V1.x to V2.x what i tries are:
I followed these steps 'https://learn.microsoft.com/en-us/vsts/pipelines/agents/v2-windows?view=vsts' but the issue is my url is http not https.
1) is there any easy way to update the build agent instead above link because setting https getting connectivity/cert issues.
Do i have only PAT is the only option? any thing else apart from PAT to update the build agent. i even tries 'update all' nothing happens and no errors.
any help would be great-full. Thanks.
No matter you are using http or https, you could both update build agents properly. If directly entire the url in the browser could not reach the right page.
You could also try to navigate to http://yourserver:8080/tfs/DefaultCollection/_projects page and clcick the configuration button, select the Agent Pools in the drop down list.
Back to the original requirement, 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.
Using on-prem TFS 2017, I have added an additional agent to an existing pool. The agent is displayed in the pool/queue management pages, is enabled, and is in an idle state. The logs reflect a healthy agent that is listening for work, but the TFS controller won't designate work to it (as far as I can tel). I have tried disabling the other agent as well as stopping the other agent's service. In either situation, the build status states there are no available agents to perform work. I have other agents running in different pools that are all functioning properly, so I am not sure how to determine whats at fault: agent/agent configuration, queue/pool configuration, or the TFS controller it self.
I finally found the issue:
While MSBuild and all the relevant Microsoft SDK's required for my builds were installed and properly reflected in the agent's capabilities, Visual Studio was not installed on the new build server.
I was not able to determine why the agent(s) was rejected for insufficient capabilities; we were running TFS 2015 update 2, but after an update to TFS 2017, the agents are no longer dependent on Visual Studio being installed and work just fine running the same build definitions with the MSBuild step.
So, I tried to upgrade my TFS 2015 to allow project with .NET 4.6.1.
I downloaded the Targeting Pack for .NET 4.6.1, ran it, restarted the server, ran my build configuration for the build agent by overwriting the old settings, and started my builds.
Now non of them will build :(
I think I miss setting a parameter somewhere.
This is my agent, which is registered, but never requested (for some odd reason):
Am I missing something?
According to your agent.version 1.95.3, seems you are using TFS2015 update3 which should definitely support .Net 4.6.1. And the system capabilities of your agent looks okay except the Number_OF_PROCESSOR. Your value is 1, but usually the default is 8. Did you manually change the value during the configure?
Recommend you follow below way to narrow down this issue:
First check in that if the build server is available and enabled in
TFS at https://YOURCOMPANYNAME:8080/tfs/_admin/_AgentQueue, and
your build agent should be “Green”.
Make sure the agent is in interactive mode.
Try to change a domain account which is a member of the Build
Agent Service Accounts group and belongs to "Agent Pool Service
Account" role, to see whether the agent would work or not.
Double check whether there are some Firewall interface block the
build, try to disable all related settings.
If it's still not work, delete that agent and re-deploy a new one following the detail steps in this article. You can also go through below similar questions to check if there is some useful info :
TFS 2015 On-premise issues
TFS 2015 build vNext - hangs with "Waiting for console output from
an agent..."
TFS 2015 Build agent won't start