I have some problems with our TFS 2015 Build in our off shore location.
We have our main TFS in Austria and an already working proxy (TFS 2013) in India.
I have created a TFS 2015 Buildagent which is also working but it is not able to gather the files from the proxy.
I have configured the build machine like it is stated on this Microsoft site:
https://msdn.microsoft.com/en-us/library/cc716770(v=vs.120).aspx
But it still downloads all the files from our TFS which takes up to 15 Minutes with a good connection.
The proxy was provided for older versions of TFS. One of the great features of the new build system is you can place the agent wherever your files are. Setup up the build agent where the files are instead of going through a proxy. You will still need to connect the build agent to the server but that may work better.
Related
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.
Using on-prem TFS 2017, I have added an additional agent to an existing pool. The agent is displayed in the pool/queue management pages, is enabled, and is in an idle state. The logs reflect a healthy agent that is listening for work, but the TFS controller won't designate work to it (as far as I can tel). I have tried disabling the other agent as well as stopping the other agent's service. In either situation, the build status states there are no available agents to perform work. I have other agents running in different pools that are all functioning properly, so I am not sure how to determine whats at fault: agent/agent configuration, queue/pool configuration, or the TFS controller it self.
I finally found the issue:
While MSBuild and all the relevant Microsoft SDK's required for my builds were installed and properly reflected in the agent's capabilities, Visual Studio was not installed on the new build server.
I was not able to determine why the agent(s) was rejected for insufficient capabilities; we were running TFS 2015 update 2, but after an update to TFS 2017, the agents are no longer dependent on Visual Studio being installed and work just fine running the same build definitions with the MSBuild step.
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 installed the prerequisite (Team Explorer 2013) to the best of my knowledge, but when I try to set up a VCS root to connect to our TFS Version Control server, I continue to get this error message:
"No TFS assemblies were found on the system. Please make sure you have
Microsoft Team Explorer installed. Supported versions: 2015 2013 2012
2010 2008 2005"
The Team Explorer I downloaded from Microsoft just seemed to be a plugin for Visual Studio, which doesn't make much sense as a server-side component. Anyway, I configured a connection to our TFS box within Team Explorer/Visual Studio on my TeamCity server.
So I have two questions that seem to be undocumented by JetBrains:
What does it mean to set up and configure Team Explorer? How can I validate that I have set up and configured Team Explorer on my TeamCity server correctly?
How does TeamCity know how to find the Team Explorer assemblies? Is there some sort of configuration I am supposed to do? Where is this documented?
I guess I'm looking for a true step-by-step set of instructions that make no assumptions about my understanding of TFS or Team Explorer, or any assumptions about what I may have already installed on my TeamCity box.
I've read the two articles on the JetBrains site regarding how to set this up, and they don't cover actually installing and configuring the prerequisites or configuring TeamCity to discover the Team Explorer assemblies it needs.
Team Explorer is the client software that you use to access Visual Studio Team Foundation Server functionality from Visual Studio. You can simply launch Team Explorer on your TeamCity server to create a team project and check in a project, to validate whether it is installed correctly.
I couldn't find any documentation that mentioned how does TeamCity find Team Explorer assemblies. But, based on my understanding, there is no configuration needed to detect Team Explorer. Please make sure your TeamCity server is running under Windows.
If the issue that can't find Team Explorer persists, you can install VS Premium instead of Team Explorer.
Setting up Jetbrains TeamCity for CI with Team Foundation Server:
Install Jetbrains TeamCity
If you are planning on using IIS or TFS on the same server, configure Jetbrains TeamCity to run on a port other than 80 or 8080
Once TeamCity is up and running, you can begin configuring your TeamCity installation for CI Builds.
Log into TeamCity with your user name and password
Create a new TeamCity Project
Create a new build configuration
You will now see a series of build configuration settings that you will have to complete presented in a Wizard-style navigation view.
Enter General Settings
Enter VCS Settings
After entering VCS Settings, Create and attach new VCS Root
Enter the relevant information for your TFS instance
Create a Build Step using Visual Studio as your build runner. You can create as many build steps as you need and specify the order of the steps (similar to a TFS Build Workflow).
For setting up Continuous Integration builds, you will need to specify a Build Trigger. CI Builds will generally use a VCS Trigger that is triggered on each source control check-in.
If you need to pass any parameters to your build, you can configure these in your Build Parameters.
That is all! You can then either run your Builds manually by clicking on the Run button in TeamCity or simply verify that your builds are triggered by the next check-in into TFS.
I would like to upload on my TFS 2015 some of the build tasks that are available here https://github.com/Microsoft/vso-agent-tasks.
I do have a problem with certain task as they do require a minimum agent version of 1.89.0. My build agents are 1.83.2 version.
Now, the question is, how do I update my agents for a given pool? If I do right click the agent pool on my TFS and choose update all agents option, nothing happens. I suppose because the latest version of my agent available on TFS is the 1.83.2.
Where can I find the latest version of it and how do I update it?
Note I'm working on premises TFS 2015 and not VSO.
Thanks
If you right-click the agent pool and choose "Update all agents", it will upgrade the agents to the version of the on-premise TFS server. For instance, if you initially installed some RC, and upgraded the server to RTM later, some agents might have lower version. Otherwise, as you mentioned, nothing will happen because all agents are up to date.
VSO has a different release model and updates/fixes to its agents are continuously delivered. That's why the version is constantly growing.
Technically it might be possible to grab the source code of the latest VSO agent tasks, and push it to the on-premise version of TFS 2015. However, it is considered an anti-pattern, and the behavior is undocumented and unsupported.
Let me quote build vNext developers from this discussion (see the bottom of the thread):
That is not a supported option. It is very likely that the agent we
have in VSO will not work with the on-prem server. You must use the
version of the agent that ships with your server.
And:
The behavior is undefined/untested. It may work, may not. The design
is for agents to get pulled forward via an auto update process
downloaded from your service. The auto update process may alter
configs/layout on disk, whatever. That future agent might call REST
apis that don't exist, etc... The primary focus for agents is on
forward compat so they can lazily get upgraded (via task minimum agent
demand, on restart or eventually a scheduled job).
Same answer as #Yan, but putting this here because the following error came from nowhere - so I think Microsoft updated the minimum requirements this week.
No agent found in pool Default which satisfies the specified demands:
msbuild
visualstudio
Agent.Version -gtVersion 1.95.0
For your own hosted agent just right click on the queue, or click the ... icon.
I had to restart the agent service after a few minutes as it didn't seem to want to by itself. Give it a chance to update properly before doing this.