We are currently running TFS 2012 with a 2012 build server and would like to upgrade to the latest TFS.
According to this link, 2012 Xaml builds are only compatible up to TFS 2013. However this link says that TFS 2018 update is compatable with Xaml builds. Would I be able to use my existing build server? Would I need to upgrade the current xaml builds that we use?
This can be confusing, so let me break it down a bit:
In general, a given version of TFS supports XAML build controllers for:
The current version
The previous version
TFS 2010 (for legacy reasons -- build servers running Windows XP, for example).
So, for TFS 2012, you can expect it supports TFS 2010 and TFS 2012 XAML build controllers.
TFS 2013 should support 2010, 2012, 2013.
TFS 2015 drops support for 2012 XAML controllers. This is also the last version for which a XAML build controller was released. TFS 2017 and TFS 2018 do not include a new version of the XAML build controller.
Therefore, TFS 2017 supports XAML build controllers for:
TFS 2010
TFS 2015
TFS 2018 RTM and Update 1 did not include XAML build support. XAML build support was reintroduced in Update 2, with the same compatbility matrix as TFS 2017.
XAML build is long-deprecated at this point. As soon as you are stabilized on a version that supports the new build system, you need to start migrating off of XAML build.
Related
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 want to move the whole team project data(source files and work items…) from TFS 2008 to TFS 2015. Can anybody tell me the detailed step by step process, as I have never done migration within TFS versions?
You would need to do a upgrade for your TFS. Direct upgrade to TFS 2015 is supported only from TFS 2010 and newer. If your TFS deployment is on an older version than that, you will need to upgrade to TFS 2015 in multiple hops. For your scenario, you are on TFS 2008 you could upgrade to TFS 2010 or TFS 2012 first and then to TFS 2015.
The general process for upgrading an existing deployment of Team Foundation Server is to:
Prepare your environment. New system requirements may require you to upgrade hardware or software.
Expect the best, prepare for the worst. The single most important step you can take here is to ensure you have a complete and consistent set of database backups.
Do the upgrade!
Configure new features. Depending on what version you upgraded from, you may need to configure each team project to gain access to some of the new features made available.
Walk through an upgrade from TFS 2005 to TFS 2015.
I'm currently running TFS 2013 on one Windows Server 2012 box and TFS Build 2012 Update 4 on another box. My question is if I upgrade my TFS Build Server box to utilize TFS Build 2015, will I need to upgrade my TFS 2013 Server as well?
Also, what about the opposite? Can I upgrade my TFS 2013 server to TFS 2015 and still use my existing TFS Build 2012 Server which is using web deploy to build and publish to various other servers on our network?
Yes, TFS Build 2015 and Build vNext require your main TFS server to be at least 2015.
The other way around, TFS 2015 can talk to Team Build 2010, 2012, 2013 as well as the new 2015 build agents of course, as long as they're updated to their latest service pack and update version.
Upgrading your TFS 2012 build server would not be too hard either, depending on the amount of customizations made to the build workflows.
I am testing the compatibility between TFS 2012 Source Control and TFS 2010 Build Agents, and I am glad to inform that they are compatible. I am wondering if there are any advantages to using TFS 2012 build agents. At this point, I have not found any information on advantages of using TFS 2012 build agents.
The 2012 build agent support the new Unit Test Runner, Lab Management environment, .NET 4.5 building, improvements in CodedUI, capability to trigger tests on a 2012 test agent, 2012 version of Code Analysis, improvements to Code Coverage and many many other things.
The main reason to support 2010 build agents, is to allow you to upgrade TFS from 2010 to 2012 without having to big-bang upgrade all build agents. When the next version of TFS comes, it will support the 2012++ and the 2012 build agents. It will no longer support the 2010 build agent.