We are currently testing whether we can replace our current build server (TeamCity) with TFS 2015 Build.
Does anyone know of TFS 2015 has built-in Nuget Server like TeamCity.
Thx
Package Management (NuGet with npm and maven coming soon) is currently only available for VSTS. The on-premises support for Package Management will come in the next version of TFS.
Source - TFS Feature Timeline for 2016
VSTS and TFS now provide built-in support for Maven Package Management to compliment its support of NuGet and npm.
https://blogs.msdn.microsoft.com/visualstudioalm/2017/05/22/visual-studio-team-services-demonstrates-how-microsoft-loves-java/
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 am looking for some more specific support details.
I have managed to persuade our management to use Artifactory.
We currently use the following, mostly for WinForms development. We have several dozen products we support.
Visual Studio 2015 Enterprise
TFS 2012 on Prem (working to persuade management to upgrade this soon)
NuGet 3.5. with Project.JSon
I am just not sure if Artifactory can support some of the older tools we use. I can't find any details on their website that are version specific. It just says it supports "TFS".
I read mention in some samples of Packages.config, but we got rid of those bad boys some time ago. Project.json is much better. Once we move to VS 2017 the project.json goes away too.
Does Artifactory support TFS 2012? Project.Json files?
Artifactory NuGet support is agnostic of how you manage your project, the only requirement is that your builds use supported clients (like the one integrated into VS). You can deploy and resolve your own packages or have Artifactory proxy a remote location (as long as it supports the NuGet API)
TFS support is provided by the MSBuild Artifactory Plugin which collects info from your build and also enables you to resolve dependencies via Artifactory, and deploy build artifacts.
If you are on TFS2012, it's still using XAML build. Which means you need to use MSBuild Artifactory Plugin.
The MSBuild Artifactory Plugin is installed as a "Project
Template" using Visual Studio as follows:
Under Tools, choose Extensions and Updates..., select the Visual Studio Gallery source under the Online section, and run a search for
"Artifactory".
Select Artifactory Template Package extension found, and click Install.
So, instead of TFS version limitation, it should be more related to VS version.
And according to the Artifactory Template Package in VisualStudio Marketplace, which including VS2015.
We currently use TFS 2013.
I'd like to do a POC where I can create some build definitions in TFS 2015 where it would get the source from our existing TFS 2013 server. Once the boss sees how much easier it is to manage our builds from TFS 2015, I'm sure he'll give us the go-ahead with upgrading the existing TFS 2013 to TFS 2015.
Is this even possible?
You could write a PowerShell script or some batch files to leverage tf.exe in order to map a workspace / clone a repo (depending on whether you're using TFVC or Git) as part of a build. Or just put the tip of your source code into the "demo" environment and build from there. The latter option is going to be much faster.
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.