I am unable to grasp the concept of build server in Team foundation. Can anybody explain ? Also what is the build agent and controller in the foundation server ?
In TFS, the build system consists of two main constructs: the Build controller and the Build agents.
The Controller's job is to queue build requests and send them to the "most available" build agent.
The Agent's job is to perform the actual build.
This setup allows you to easy grow into a "Build Farm", which the controller is dispatching to any number of agents, allowing your build platform to scale without being redesigned.
The phrase "build server" or "build machine" simply indicates a server on which the build controller, the build agent(S), or both run. In a smaller shop, you'd probably only have one build machine and it's likely that box would also be doing some other actions.
The MSDN info is pretty good on this, as are any # of blogs.
MSDN: Build Machines
http://msdn.microsoft.com/en-us/library/ms181712.aspx
MSDN Build Controllers
http://msdn.microsoft.com/en-us/library/ee330987.aspx
MSDN Build Agents
http://msdn.microsoft.com/en-us/library/bb399135.aspx
Related
I'm looking for a tool of some kind that i can integrate into our CI process to keep track of the manual steps we have.
As an example, we want to run through some manual test scripts on the integration server before pushing the version to the test server. Currently QA gets a notification when the build is done, executes the manual testing and then tells someone to push the version to test if it's okay.
What i would love to find is something that will keep track of when the manual tests have been successfully completed and automatically push the version to test.
It should will be possible to notify/trigger the tool from Visual Studio Online and have it trigger the next step in VSO as well.
I've been googling various different things, but can't seem to find anything close to what i'm looking for. Todo list tools like Asana doesn't seem to have the integration point we need, but maybe i'm just missing something?
You can use the new Release Management tools in conjunction with test cases to get what you want.
In VSTS you can create test cases to reflect the steps of the tests that you want and then create a Test Plan or Suit to reflect the list of tests that you need to run manually.
Then as part of your release process you could create a custom task that waits for a Test Run to be completed against you list. If that test run has all pass then move to the next step, if any tests fail then fail the release.
This should be fairly easy to setup and you need to call the API to check the Test Run. If your Testers use Microsoft Test Manager you can also have the results associated with the Build that you are deploying and get full traceability.
You can try with the Release Management tool in VSTS. It can achieve partial features you want.
I assume you have three steps in your build definition:
Build solution
Publish to integration server
Publish to test server
You can keep the first two steps in build definition. And then create a release definition in Release Management and add the third steps in it. Configure the definition to "Continuous deployment" and link it to your build definition. Assign your QA to be the approver for this release task. Now, a release task will be created as soon as a build task completes. But it will be pending for the approver (Your QA) to approve. Approve the release task after the test is passed, the build will be published to the test server. Otherwise, reject it.
We're working on setting up a TFS server for our work, and I'm in charge of getting the build working. I have had no experience with TFS before, but setting the build controller and agents up using the wizards was easy enough. We have the TFS server on one machine, and a build controller and build agent on another machine registered to the TFS server.
When I start a build from my developer machine, the build reports as having started and the status of the controller changes to something like "running build vstfs://Build/Build/16". However, the status of the Agent never changes from "Ready" and the build hangs indefinitely. If I stop the build from my developer machine, it reports that the "build was forcefully stopped by the server because the build machine did not respond to a stop request", and the build controller still has the status of "running build". I need to restart the build controller in order to reset the status.
I've checked that port 9191 is unblocked, and I can telnet into the port from my developer machine. The server also seems to be able to communicate with the build machine, as the controller is receiving build requests, but I have no idea what to do from here. Any TFS experts have any idea what might be happening?
Thanks,
Zach
Found the problem.
Under the build service properties, We had the value "Listen for build agent communication on:" set to [BUILDAGENT.companydomain.com:9191/Build/v5.0/Services. We needed the value to be just [BUILDAGENT:9191/Build/v5.0/Services]
I have been trying to Setup TFS with continuous integration on Local Network, where we have 3 developers to check in code.
Which method of deployment should i follow to achieve this
I found these option
Deploy TFS in several ways: on one server; on many servers; or in one domain or workgroup or across domains.
and are there any tutorials to follow.
If you want to setup a CI pipeline, it is not necessary to deploy your TFS on several machines. More important is to setup a build controller on a separate machine. With that you end up having the TFS on one machine and the build controller on the other. Also you should customize the build process the way you need it. This really depends on what you want to do, f.e. running multiple build process one after another.
Our team has a full licence for the TeamCity server, as well as 7 additional agents. Another unrelated team has reached the limits of their free TeamCity licence and is eyeing our licences up.
The powers that be think it's a good idea to run both teams using the same enterprise licence, which means that we'd be hosting the TeamCity configurations on the same server, and either sharing agents or somehow assigning some agents to one team, some to another.
One concern I have is that configuring an agent to only accept certain builds is difficult - our team has hundreds of build configurations, and we create new ones all the time. To limit an agent to certain builds, you have to fully specify the whitelist. So maintaining the agents such that we have full use of some agents, and the other team has full use of theirs will be a pain. On the other hand, just using one pool of agents means now you have arguments over priority and starvation, etc.
Does anyone have any experience of this? Is it a workable solution? How do you configure agents to reserve them for a particular team? How do you configure the server so that each team only sees their own projects, build configurations and agents? Basically what we'd want is complete separation of the projects, just using the same TeamCity server and agents.
As a gut feeling it doesn't look like a good idea...
edit: As an aside, does Hudson do this better? The ivory tower architects want us to change from TeamCity to Hudson because other people are using Hudson. If I tell them this sharing TeamCity won't work, the Hudson camp will probably use it as a stick to beat us with. Joy.
Not sure what version of TeamCity you're using but the newly released TeamCity v7.0 now has a new Agent Pool feature that provides a much easier way to distribute agents. It may be of interested to you, check out the What's New section or the Agent Pools docs for more info.
I had a similar issue with our two departments starting to share the same TeamCity instance to save the expenses of additional licenses. I must admit we didn't really have any issues apart from our agents were now twice as busy.
I enabled Per-project permissions on the Global Settings page and created 2 user groups, one for 'us', and the other for 'them'. You can then configure each group's roles accordingly. If a group does not have the Project Viewer role for a project then it does not appear for them - a great way to only display necessary projects to the group; but there are plenty of other role options to use.
I have never used Hudson so can't compare unfortunately. I should really try it out but as I've always got on so well with TC I've never had a reason too.
You can make builds on run on certain agent, from the build configuration of each build in the agent requirements section, thereby limiting any build configuration to certain agents.
For example if your agent for one team is teamcity1 you can specify:
system.agent.name does not equal teamcity1
So it will never run on that agent.
That way you can at least copy build configurations and they will run on seperate agents without the fiddle agent configuration.
The other team can create a new Teamcity server, and it will have its own new set of free build configurations and agents.
We don't do this any more, but we used to split our agents into pseudo-pools so we could reserve some for compilations and others for automated tests (because automated test jobs can swamp the grid). We added a "can_run_tests" property to the test agents, and made those builds require that property as an agent condition. It worked great, and it's the sort of thing you can bake into the AMI for a set of cloud agents.
What we do now is to make the compilation and test builds require on different AMIs, which does essentially the same thing.
I'm developing a project in C# using VS2010. I'm using svn 1.7 for my version control. What I want is a (FREE) tool that runs on the build server and checks for fresh commits. If the commit breaks the trunk then I want email notifications sent (I have a sendmail openbsd server on the network I can use). I also want this tool (or another tool) to run all my MSTest tests periodically and send emails if there is a failed test.
Any suggestions? I already built my own crude windows service to check for failed builds. But this was before I heard that tools for this sort of thing already exist. I could easily have this thing run all my tests with mstest.exe and then parse the xml results files, but I'm wondering if my time would be better spent just installing and configuring a proper tool for all of this.
There will be at most 4 developers.
Thanks in advance for the help!
I have some experience with TeamCity and Hudson/Jenkins.
I found TeamCity fairly easy to setup and it seems to meet your needs of:
MSTest integration out of the box
Email notifications
TeamCity is free for up to 20 build configurations and has an easy to use Web/GUI interface.
Have a look at CruiseControl.Net
built in support for Subversion
no limits on number of build configurations
email notifications using the 'Email Publisher'
web interface and desktop build notifications via CCTray