I'm working on automating our build process using Team Foundation Build 2010. When our TFS Server was installed, whomever installed it didn't install the Build Configuration Services so this node is missing from the TFS Admin Console. I'm pretty sure I know the answer to this but I wanted to check in case I'm missing something. I'm also asking because the TFS Server is a production server and my supervisors do not want to install anything on this server. Can the Build Services be installed on another machine or VM and still have the Build Configuration Node appear in the TFS Admin Console? I know the Build Controller as well as the Build Agent can be installed on another machine or VM. I just wanted to get clarification on the "Build Configuration Services" piece. Thank you
Absolutely! This is actually a very typical scenario. I don't normally recommend for people to install the build services on any of the application tier servers. When you install only the build features, the TFS Administration Console will show only the build features.
By installing it on separate machines, you can create a build farm of a build controller with multiple build agents. It scales very well.
Build servers would be considered "production" servers in my opinion as well. They don't have the same disaster recovery or monitoring requirements though. If a build machine dies, just image another one and add it to the pool. This is essentially how the elastic build service for the Team Foundation Service (aka TFS Preview) currently works. They get destroyed after each use.
Related
I have a windows service project that has a Build ready and now needs to be installed at the target machine and run. There is no task in TFS Releases that allows that to happen. What are my options other than writing a custom PowerShell script?
For the current approach, you need to install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers.
The simplest way is using remote powershell task to achieve the installation. Details about the task please take a look at Deploy: PowerShell on Target Machines
In the near future, you could also use Agent-based deployment in Release Management. For this, you can install the agent on each of your target servers directly, and then drive rolling deployment to those servers. More details please refer this blog: Agent-based deployment in Release Management
You can do this easily with Team Build.
You use the "Copy" task on the Release tab to send the files to the machine that you want, and then run a remote PowerShell to do the installation.
You can even deploy the same Windows service to 10 machines using "Machine Groups".
At our office we have Team Foundation Build machine (visual studio 2010) that we are looking to move to either a new physical server or possibly a VM. Although I have found a lot of information regarding the backup of Team Foundation Server I have not been able to locate much information on backing up a Team Foundation build machine so we can restore it on another machine/VM.
Any advice or a link would be most appreciated. Thanks.
There is no TFS specific data stored on the build machine, so from a TFS perspective there is nothing to backup/restore.
To setup a new build machine, just install the TFS build software, and point it to your TFS Collection.
The thing that will take time to reconfigure is any software or SDK's you may have installed on your build server that are required by your build. This has nothing to do with TFS, and is difficult to backup and restore to a different machine.
One option is to use a P2V tool to convert your physical machine to a VM, then you can move it to any host.
Otherwise, you are probably looking at just rebuilding a build server and redoing the installs necessary. This time be sure to do it in a VM so you can easily move it around between hardware in the future.
I prefer to avoid the Magical Build Machine Anti-Pattern and focus on writing the 'build the build server' scripts. Even if it's just a simple batch file, have a way of starting from basic windows and build your environment. Whenever you add a dependency, update it. This also helps you scale out. (At a previous company we had over 75 build servers.)
We recently upgraded to TFS2012 and now we have an MVC app and a WCF Service both built in VS2012 that WILL compile and build but will NOT deploy. Any ideas on what I should research? I read that MS now only allows deployment of certain types of files and web files are not of that type. Thanks so much for your time.
The default build processes in a standard on-premises TFS2012 installation do not do any deployment out of the box. Therefore in answer to your question I would personally look at the custom deployment steps that are happening and maybe put some additional logging in to identify the problem.
Often being able to remote desktop into the build server and then perform the steps that your build process would have taken is a good way to check things like this.
As the upgrade process usually involves re-installing the build agent my guess would be that it could be a permissions problem, maybe the build agent was installed as a different user to how it was running in the TFS 2010 configuration and that process/user does not have permissions to deploy the build. But that is just a guess - digging into the deployment steps that you added to your build process should help you track it down. Good luck!
I am going to be responsible for implementing TeamCity into our development environment pretty soon. I have searched around and see no real answers, does anyone know if there is a 'best practice' when it comes to a build server. Is it Ok to install TeamCity on the same server as TFS, is it preferred? Or should I install it onto a dedicated server (which I can do).
Thanks
I would think that Microsoft's own advice about TFS would also be relevant here:
You can host a build server on the same computer as your Team
Foundation Application-Tier Server, but, in most of these situations,
this build server should not host any build agents. Build agents place
heavy demands on the processor, which could significantly decrease the
performance of your application tier. In addition, you might want to
avoid running any build server components on the application tier
because installing Team Foundation Build Service increases the attack
surface on the computer.
So, you might see unnecessary slow downs on other operations like version control, work item tracking, etc.
Install it on its own server, you don't want it grinding tfs to a halt when it is performing a build.
You could install the Teamcity server on the tfs server but if you can a separate machine, but as its the agents that do the work it those that definitely need to be on a different machine from teamcity and tfs if possible.
I have created a lightly customized TFS build process template and also appropriate TFS build definition. It builds fine on the TFS build server.
Is there any way I can allow developers to reuse the same build process XAML and definition to do full builds on their local machines? Maybe there is some utility which can be run with TFS build process XAML files?
I really would like to avoid maintaining a separate copy of the build script for full local rebuilds.
The build templates can only be run by the TFS build service. Without installing that on each developers machine, that might not be the best idea.
An alternative is to setup a share on the developments machine and grant access to the TFS Build account (the one that TFSBuildServiceHost.exe runs on the server as). Then the developer can Queue a build and get the Server to Drop the files onto their machine.
The downside to this is you need a lot of builds to be run on the Agents.