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.
Related
I'm in the process of establishing a dedicated build machine with several build agents for doing CI/CD for multiple team projects.
I've configured one agent pool against our TFS server, and installed 10 agents from that pool as services on our machine.
Our work is mostly .net but we do have some python and js stuff as well.
My question is what are the pros/cons of using one machine with all the toolsets/dependencies?
Is there any good practice that i'm missing? I would love to hear some opinions.
Yes you can run multiple agents in a single machine. You might want to have multiple build agents to be able to run builds in parallel.
The biggest advantage is that avoid all the upfront capital costs (physical servers, MSFT server licensing, etc). And you just need to deploy the build machine in one time (install the toolsets/dependencies etc).
However please note that builds are typically IO constrained (disk/network read/write speeds), also constrained by the memory/CPU consumed. So running too many parallel builds on one machine will actually degrade the performance. Also may affect calls to the TFS and possibly lead to time-outs.
Besides, you may need to install additional or upgrade software components on the build server and that may need a reboot to take effect, this may affect the current building. Although you try to limit this as much as possible, eventually you could end up with conflicting software as the project advances and interrupting the existing builds.
So, recommend you to deploy separate build servers with the agents installed separately on each of them. That means use multiple build agents to support multiple build machines (e.g.: with 3 build machines - and 3 build agents - to distribute the load).
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'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.
We recently moved to Team Foundation Server 2008 from Source Safe. We are setting up some automated builds and have run into some issues with the publish of click once apps that seem to require additional installs on the build server.
I've seen posts that indicate that the Visual Studio IDE needs to be installed. I've also seen posts that say that installing the .Net Framework SDK would fix the issue. We don't want to install more than we need on the build server, but we also don't want to have to make multiple requests to our server team to install different pieces at different times. So, I'd like to know what most teams end up installing.
If it's important, we don't have a dedicated build server at this point. We are a small team (6 devs, all local). Builds are happening on our main TFS box, the SQL Server piece is the only part that is on a separate server.
If you are just compiling applications in with Team Foundation Build, then the .NET Framework will do - however as soon as you start wanting to do anything more advanced (such as running unit tests and having their results published into TFS) then you will need to bite the bullet and install a Visual Studio Team Edition on your build server. I usually just install a copy of Team Suite on the build server so that people who are licensed to use the various features can have those features run as part of any automated build.
Having to have it installed on your server is not ideal, but gives you the best experience at the present time.
Regarding using your TFS server as your build server, this is not recommended for larger teams because builds tend to be pretty CPU and IO intensive beasts - however for a small team such as yours and assuming that you don't have too many build definitions that could run at once you should be able to get away with it.
According to this, Visual Studio shouldn't be required--just the .NET Framework. One other note to consider from the link is that they recommend against builds happening on the TFS box.
Yes, I installed VS on the build server. I followed their manual for setting up TFS.