When queueing a new build, we get the option to change the default parameters. Do these changes get recorded somewhere, either in the TFS Operational Store or in the TFS Data Warehouse?
These parameters should be available in the Team Foundation Build Operational Store, according to the behavior described in http://msdn.microsoft.com/en-us/library/ms244687.aspx.
My advice is to log them as part of the build workflow, then the log will be stored with the build outputs. If you read the ALM Ranger Build Guidance they suggest taking this approach, and I believe the BRDLite customized Build Process Template that ships with the guidance does this: http://rabcg.codeplex.com/
Related
Does anyone know if the feature to tag agents has dissapeared?
I could not find anything related to over the internet.
My idea is to have certain builds use a specific agent. On TFS 2013 I would use tagging, but i no longer see that option.
On the other hand, I see that it is possible to connect a build definition to a certain agent queue.
There is no more agent tags for TFS 2015 or later version. If you want to use a particular build definition and a specific build Agent which used to run the build.
You could add a user Capability to that specific build agent then in the build definition you put that capability as a demand (General tab).
Another way is directly using Agent.Name or Agent.ComputerName demands in build def or when queuing a build. Take a look at this blog: How to send TFS build to a specific agent or server, which also support on TFS2015.
Oren: Is this feature works in TFS15 SP3?
Reply Eric Parvin: Yes, this should work on TFS 2015 to the newest version.
Use demands and capabilities for this. Add a custom capability to the build agent, and then add a matching demand to the build definition.
Demands and capabilities would work, and you could also create a specific queue, with a single available agent in it, and set the queue to your desired build, so you would achieve the same behavior as desired one.
I've been tasked with migrating a build from TFS to VSTS, I've used TFS from a developer point of view, however I've never created builds. Can anyone give me any advice where to start, good websites, tutorials, tools that might help, anything that might catch me out etc, basically my knowledge on this is very limited so anything would help. I've no doubt there must be somebody out there who can say we've done this, here is what we did...the new VSTS build will need to be a copy of the TFS build however some analysis needs to be done as the build process is old and certain parts may not be necessary. Thanks in advance!
Migrate New Vnext build definition from TFS to VSTS
If you want to template your builds or move them from TFS to VSTS, you could also use the REST API's to perform this. Details please refer this blog: HOW TO MOVE BUILD DEFINITIONS IN TFS TO OTHER PROJECTS USING THE REST API
Another example shown here. It shows how to get the JSON response of a build definition and again using the same reference to make a new one in the project you desire.
Migrate Old XAML to New Vnext build definition from TFS to VSTS
Unfortunately, there will not be any automated conversion processes. The new builds are based on a different architecture and run on a completely different system. And you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
If you have heavily customized XAML builds and custom activities, you
can continue using those builds until you are ready to port your
business logic into scripts that can run in the new builds.
You should also take a look at these series of articles by jessehouwing devoted specifically to the case like yours.
About how to create a build, you could refer this tutorial from MSDN.
In 2009, there was a SO question on the same topic.
I'm wondering if later versions of Team Foundation Server are better at longer build pipelines. Refer features of Jenkins, TeamCity, ThoughtWorks' Go (my employer).
The visualizations of the build pipelines are important to me, as well as the notification about individual stages passing or failing. That and the eminent clone-ability of say a 'trunk' pipeline into one for a release branch as that branch leaps into being.
Secondly, a personal holy-grail is the CI server storing its config in the SCM that's holding the buildable thing itself, and even picking up on the creation of branches silently to provision new pipelines; Can TFS be configured to store the CI definitions/scripts in its SCM side rather than its accompanying SqlServer?
TFS build consists of three components:
The build definition - stored on the SQL server data tier.
The build workflow - a XAML file stored in the source control.
The supporting MSBuild scripts - usually contains user defined actions, also stored in the source control.
As the build progresses, you can see visualization of the build steps and you also get a different log for the main build and the MSBuild output.
The build definition in TFS is merely a collection of build settings, similar to CC.Net's config file and TeamCity's build configuration tab which both stored on the file system as well. Assuming there's a backup plan on the database you don't really need to store the build defintions on the source control, but if you must it's possible by exporting the tbl_BuildDefinition table.
The TFS Power Tools adds cloning functionality for build definitions.
There's no OOTB support for provisioning build definitions from a new branch though it's fairly feasible using the TFS-API.
Bit late to the party, but just don't bother with TFS if you want advanced build pipeline automation. It simply doesn't cut it.
I have used Jenkins and TFS both extensively. Tfs is just. pure. crap. Here's why.
No down/up stream build.
No piepline/orchestraion build. (like jenkins)
Obscure ways of adding build steps and falls back to using MsBuild.
Slow and still polls the source control.
Ties you to MsTest.
And please don't point me to "Oh look you can do everything if you write a custom activity". I'm not wasting time doing development for a closed source, sub-par platform. If I am going to contribute something, it's to a FREE. OPEN SOURCE platform.
Currently we are using StarTeam to perform the build as well as versioning. we planned to migrate startteam to TFS2010. We have some script for perform the build. i wanted to change this script according to my requirement. i gone through the TFS but i had lot more confusion.
in StarTeam, we will get a files from "Ready to Build" label and perform the build. In TFS, how we are going to get a files from TFS? What concept should i use to get a files and perform the build? i have gone through the lot of commands like get, check-in, checkout etc..
If we use "tf get" command, we can get all the files from TFS but i have a clarification on that. shall i get all the files from TFS for every build? i hope, this is unnecessary headache.. correct me if i am wrong..
how we perform the build in TFS? i have read some types of build such as manual, gatedcheckin, Continuous Integration and schedule.
Is there any relationship between branch and build activities?
In TFS, What is the meaning of Workspace?
As said, many questions in one. Hope this helps along the way:
A workspace is a mapping between the server and a local storage,
similar to checkout in Subversion, view in ClearCase, etc.
"TF get" normally only fetches those files that have changed since
last update. You can force it to fetch everything - and sometimes
have to - but its not normally done.
Team Build is the recommended system to build with when using TFS. It can take some time to get into (Windows Workflow-based), but is quite powerful. There are default process definitions that set up the most common actions for you.
By default, you can't control whether to build by setting a certain label, but you can define that only this label should be used when builds are triggered. Labels in TFS work a little differently compared to other VCS, though, so maybe there's an 'opportunity' to re-think your build process along the way. If you're set on using a label as before, you'll need to build a Custom build activity.
I am told TFS can accept data on build/test metrics from 3rd party continuous integration tools. Does anyone know how this works or have any good links for me? My google-fu seems weak today and I cannot find any info on this. We would like to have a short powershell script or app run at the end of the build and send all known metrics up to TFS so it could show up in certain reports. I actually would like things that (I think) should already have space for in the data warehouse for TFS BUild Server, but I will be using CC.NET. I am thinking build name, result (Pass/Fail), Number of Warnings, Number of Errors, Time, UnitTests Run, UnitTests Passed, Code Coverage, FxCop resultsThanks.
I'm afraid that there is not a ready made integration that does this yet. The plug-in that links CC.NET to TFS is available over at CodePlex but this just lets CC.NET use TFS for version control and doesn't allow the results of the builds to be published back into TFS.
To get the data into TFS from CruiseControl.NET you have a couple of options. You could write your own custom TFS Data Warehouse Adapter which is complex but ultimately flexible or you could use a combination of the Team Build API and a little bit of vodoo to push data in to the TFS Build store that would also get pushed into the TFS Data warehouse. However, this would be limited in TFS2008 as you would only be able to push data about the build and the unit tests but not things like Code Coverage.
That said, pushing data from CC.NET to TFS is something that I originally wanted to do. However in TFS2008 the built in build system was so good that I switched from using CC.NET to trigger the builds to using TFS to trigger and manage the build. This had the advantage that all the stats stuff was taken care of automatically (and the built in UI in Visual Studio). Because I moved to TFS2008 I then lost the motivation to get the CC.NET stuff built.
If anyone wanted to contribute a TFS build result publishing feature to the CC.NET integration then feel free to join the project on CodePlex - I would love to have any help going.