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.
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.
The version of ours is 16.131.27701.1:
According to https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=vsts I should see the Pipelines menu somewhere. I guess our TFS is too old, so which version do we need and are there any known regressions between the version we have and the one with the pipelines?
Pipelines are comprised of the build and release features, which are available under their respective menus in on-prem TFS. They were renamed to "Pipelines" when VSTS was rebranded as "Azure DevOps".
However, TFS 2018 does not support YAML builds. You will have to use the visual designer.
To answer the "What version supports build/release" more generally:
TFS 2008 introduced a build system that used MSBuild files.
TFS 2010 introduced a build system that was based off of XAML and Windows Workflow.
TFS 2015 RTM introduced a build system that was based off of JSON files. This is the first truly cross-platform build system.
A future version of TFS / Azure DevOps Server will support YAML build.
As for release:
TFS 2015 Update 2 introduced the first native release management tool. Prior versions had a separate client/server application called Release Management Server. It was first released for TFS 2013, but supported older versions.
So, in essence, TFS has supported builds since TFS 2008 and release management since TFS 2013.
We installed the newest TFS Server (TFS 2018 Update 2) which should run xaml builds.
After the update, we started our agent, but our xaml-controller is still offline and I don't know how I start this again..
Any ideas what we can do?
Yes, you can now upgrade to TFS 2018 Update 2 and continue to connect
your XAML controllers and run XAML builds. When we removed support for
XAML build in TFS 2018 RTW and Update 1, some of you could not upgrade
due to having legacy XAML builds, and we want to unblock you. Although
TFS 2018 Update 2 supports XAML builds for your legacy builds, XAML
build is deprecated and there will be no further investment, so we
highly recommend converting to a newer build definition format. See
the Evolving TFS/Team Services build automation capabilities blog
for more information about XAML build deprecation.
When you upgrade to TFS 2018 Update 2:
If you have any XAML build data in your team project collection,
you'll get a warning about the deprecation of XAML build features.
You will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds.
If you need to create new XAML build agents, you’ll need to install
them using the TFS 2015 build agent installer.
XAML Build Controller/Agent info is now under Additional Tools and Components > XAML Build Configuration in the TFS Administration Console. Make sure your build services on the same server as your application tier. You possibly didn't re-configure your XAML build services after the upgrade. Try this and then check again.
Thanks #PatrickLu-MSFT!! through your help, we found a workaround.
Now we use one server for the Source Control etc. (TFS 2018) and another server only for the xaml-app-controller with TFS 2015.
So we can build our projects, and have time to create new build definitions.
I am very new to Jenkins and sort of new to build .net application, but the guy left team so I have been assigned to do this. I have read tons of articles online about setting up Jenkins master, but little about slave configuration. The guy created a new slave and connect with Jenkins master successfully before he left. And he told me that slave is responsible for 1) downloading source code from TFS server and 2) building them.
now my issue is what do I need to install in the slave machine( windows system) to be able to perform that two tasks?
1) for downloading source code, do I need to install TFS client on slave ?
2) for building source code, do I need to install MSbuild or entire Visual studio ?
Thank you very much !
Assuming you installed a recent version of the Team Foundation Server Plugin, then no TFS Client is required (see https://github.com/jenkinsci/tfs-plugin#400-and-later-new).
Depending on what you are building, installing Visual Studio maybe required or not. In my experience, only a limited set of project types build with just MSBuild and without Visual Studio. There are hacks or supported tips but they work only in specific cases: YMMV.
The new Build Tools for Visual Studio 2017 RC are making this requirement a thing of the past: if you can migrate your code to Visual Studio 2017 you will be able to use them.
I've searched for answers to my question on this forum and elsewhere, but so far unsuccessfully.
We are upgrading our toolset from VS2008/TFS2008 to VS2013/TFS2013. We now have TFS upgraded (phew!) but the big questions remaining are:
We have a single build agent using Team Build 2008 running on a Windows 7 x64 SP1 machine, with build results published to an old XP machine. Will the new TFS2013 server be able to work with it fully, or are we compelled to upgrade the build agent to Team Build as well? if so, does Team Build 2013 run on Windows 7 x64 SP1 or will we need a complete new server platform?
If we are compelled to upgrade the build agent to Team Build 2013, will/should our existing build scripts continue to work?
Can anyone advise?
The answer to your question is, "It depends."
The build system was totally redesigned in TFS 2010 to be based on Windows Workflow build process templates instead of MSBuild files. TFS 2010/2012/2013/2015 can all run old-style MSBuild files by using a build process template called "Upgrade Template". Whether they'll work immediately out of the box depends on how customized your MSBuild files are and what (if any) custom assemblies you're using. Custom assemblies may need to be recompiled, or may need code changes to continue to work.
TFS 2008 build agents do not work with TFS 2013. You will need to upgrade your build agents. However, TFS 2013 and 2015 build agents will both run on Windows 7 SP1, so you're good to go there.
The build system was revamped again in TFS 2015. My recommendation would be to get on TFS 2015 ASAP and skip the XAML build system entirely. The new build system is much easier to work with and can be extended with far less pain.
You are in a scenario with a fair amount of risk, especially if your business depends on your CI builds running regularly. Your best bet will be to do a test upgrade of your environment and validate what steps will have to be taken to ensure your builds continue to run against the Upgrade Template, or how much effort it will take to retire your MSBuild-based build templates and switch over to a newer build paradigm.
Regardless, I would strongly recommend making the move to TFS 2015 over 2013. Why go through the effort of upgrading from 2008 to 2013, only to still be a major version behind?