I have just upgraded our TFS 2008 to TFS 2010. We have a few project areas in our source control and in 2008 they all seemed to have their own build queue, i.e. we could have 2 builds going on if there were in different projects.
However in 2010 there seems to be only one queue. If i queue a build in project A and there is already a build going on in Project B, the Project A build wont start until Project B's build completes.
Can anyone shed any light on this matter?
Is it a configuration/setup issue that can be altered?
In TFS2010, each Collection has a Build Controller associated to it. Each build controller can have 1 or multiple build agents running your builds. So you can build multiple solutions in parallel, just the setup of the build environment is more advanced and scalable than in previous releases.
Take a look at this : TFS Team Build 2010: What’s New?
Related
We have migrated TFS2010 to TFS2015sp3 and we would like to use the existing TFS2010 build controller & agents (XAML) with TFS2015.
As a sample test, we did a clone of the existing TFS2010 controller and on the new machine we pointed the Project collections to the new TFS2015 URL.
I see the build controller and Agents in running state, but when I queue the build it keeps on waiting for build agent, even though the agents are online.
TFS 2015 still support XAML Builds as long as you use TFS2010/TFS2013 XAML Build controller.
Please make sure your build control version are the same as build agent version. So if you are using TFS2010 build control, you should also using TFS2010 build agent.
You could also create a new build control TFS2015 and build agent 2015, test if the build works properly.
Even though the build agent and control is online, you should also double confirm you have selected the right one in the drop list when you queue the build.
Besides, please also verify that your controller has "Maximum number of concurrently running builds" set to a number higher than 0. The default to number of agents can sometimes go wrong.
You set this on the controller properties in the TFS admin console.
You can also try remove the agent from the controller and add it again.
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.
So here's the setup we have right now
1) We use TFS2013 for our code repository
2) We use TeamCity to do our builds
3) we have our tests created in CodedUI
From what I've read online is that for the CodedUI tests to run automatically, they need a build to reference. However, since we are using Team City to do the builds, our Build Explorer in TFS is empty. Switching off of Team City for builds is a no, so I'm trying to find a way to have the builds appear in the Build Explorer so I can have the automated tests run via MTM.
TL;DR: I need to get the Team City builds to appear in the TFS Build Explorer.
I saw this question, but it was for 2010, so I'm hoping it's changed since How do I make a TeamCity build appear in the TFS Build Explorer?
It can be done using the API. You could use the following blog post as a starting point to create an app that records in TFS the results from your TeamCity build. Then you could run your app as part of your TeamCity build.
http://blogs.msdn.com/b/jpricket/archive/2010/02/23/creating-fake-builds-in-tfs-build-2010.aspx
Update: There are however downsides. Some capabilities of ALM are only available if the build is done in TFS. You loose Test Impact Analysis, relationships between builds and Work Items, identification of Verifiable Bug fixes, roll up for release management of release contents.
TF Build is more than just orchestrating a compilation, it is the glue that knits your ALM strategy together and you will not be able to amortize the realm value in TFS without builds in TF Build or a whole lot of custom work.
Sorry, it's not possible. Team Explorer is designed to show you Team Builds.
I have a TFS 2010 with some projects and a common library used in 5 of them. We use VS 2013 and we have Rolling Builds enabled in most if not all build definitions. When the common library is checked in, all of the projects referencing it are recompiled - but the order is poor, the most commonly used project is compiled as the last one. Is there a way to change that so it gets compiled first?
This question hints at a lot of problems and possible solutions. The simplest answer is probably to just add more build servers to run all the builds in parallel.
Otherwise you need to consider turning off rolling builds and writing your own build scheduler. That or other strategies such as building the DLL once and checking it in as source to the other builds or running the build on a branch that is outside of the other 5 builds and merging the source into those builds when they want to pick up the change.
If you are otherwise happy with how things are now and don't want to do a lot of work to solve the problem.... then just scale out your build farm with additional agents.
There's a "Priority in queue" on the build definition, but it sounds like you might want to change your solution's > Project Dependencies' > Build Order?
I am working with Visual Studio 2012 .NET 4.5 ASP.NET MVC 4 project that uses TFS for source control and TFS Build for continuous integration (CI).
I want to create functionality that on each check in the build number gets updated prior to the CI build is kicked off.
From research it seems that a custom activity can be created and integrated in TFS 2010 build template.
I have also seen examples of this can be achieved with MSBuild task.
I haven't done work in this area before, so I am wondering which is the better approach or the recommended approach based upon the options open to me? In general when would I use MSBuild tasks as oppose to custom activity? For example, I will be looking to run FxCop and StyleCop against check ins also in the future, so I would like a common approach to this.
In the case of incrementing the build number, I'd vote for the TFS Build Activity so that the implementation is not tied to your msbuild implementation. This allows you to easily apply the TFS workflow activity to any number of branches without tying it to the branches directly. In addition, it keeps your MSBuild project files clean of the task so that it isn't mistakenly executed on developer machines.
Holistically, I'd say that you need to take a variety of factors into account when deciding between MSBuild and Workflow activities:
1 - Does MSBuild support the functionality out of the box (like Code Analysis/FxCop)?
2 - Does the build step need to run on developer boxes as well as servers (StyleCop/FxCop)?
3 - Does the build step need to interact with the TFS API or source control directly (checking out/in a version file for incrementing)?
4 - Are you going to change build job schedulers later to something free (for example, Jenkins)?
It's the combination of these things that determines the implementation of any given tool integration in my book. I'd implement FxCop, StyleCop and any other tool that should be run on a developer box build via MSBuild. I'd implement build steps such as version incrementing, bin-placing and CI deployment invocation (for example, deployment of a SharePoint webpart as a post-build step) via a Code Activity or some scriptware.