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.
Related
I am developing a Sitecore solution locally using TDS. Our source control and build server is Visual Studio Team Services (in the cloud). I would like to figure out a way to implement Continuous Integration and get builds to be automatically installed on an Integration server that is an Amazon VM (or it could be some other externally located server). I have the TDS build configuration set up to create a Sitecore Update Package. The build process works great. At the end of the build process I have the Sitecore Update Package sitting in a Drops folder in source control (TFS in the cloud). Now I can't figure out how to automate the process of getting that update package out of source control and downloading it to the Integration server and running the Sitecore command to install it.
In a perfect world you would use something along the lines of a fancy Microsoft Release Management to deploy it to the environment of choice. However, if you are like the majority of us mere mortals without the fancy tools - this should help: https://github.com/adoprog/Sitecore-Deployment-Helpers
With these pages you could just send a get request from TFS or use the logic to write a custom PowerShell post-build script. Hope this helps!
As you are using TFS you get to use Release Management for Visual Studio out of the box. This is a simple install but at this time is separate. I have an instance of RM running in a VM and attached to my VSO instance for running deployments.
I would expect this tool, which was bought by MS last year, would become more integrated in vNext.
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.)
I am trying to get the most basic configuration of TFS 2012 up and running.
So far I installed the TFS server using the simplest option (the 1st option in the installer - the one that comes with a bundled SQL express),
I configured the build service (1 controller, 1 agent, both on the TFS machine).
My project consists of 2 parts: a C#/silverlight part, and a C++ part.
After adding the silverlight prerequisites the C# project builds correctly.
However I can't get the C++ project to build.
I guess I am missing a prerequisite since I am getting the following errors:
C:\Builds\1\proj1\Client\src\Code\Client\proj\main (VC11).vcxproj
(19): The imported project "C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\v110\Microsoft.Cpp.Default.props" was
not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
Indeed, the TFS server does not have a "C:\Program Files (x86)\MSBuild\Microsoft.Cpp" folder (while my dev machine has one).
I installed the windows SDK, but that didn't help.
I saw on some posts that I need to install VS 2012 on the build machine. Is that correct? will VS express do?
I have been banging my head on this for the last 2 days, and any help would be appreciated.
Installing Visual Studio on your build server seems like a strange thing to do, but having been around the TFS block a bit, I have found it to be the simplest way to manage build servers.
You can copy the files manually from your dev machine to your build server, but if an update to visual studio comes out, you will need to figure out what has changed and make sure you update all those files too. These files typically include Targets files and associated dlls.
Also with all the extensions and packages that are available now, it is just easier to load Visual Studio on your build server and install the required packages than try to work out what is needed to replicate the functionality.
This was made very clear to me recently when Microsoft released ASP.Net and Web Tools 2012.2. This altered the publishing pipeline for Web Sites and Web Projects and I needed to use this in my TFS build. It was so much easier to just be able to log onto my build server, load Visual Studio and download the new update.
I would definitely support installing Visual Studio on your build server.
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 want to create MSI build package as part of a TFS build.
What options there are?
i know about:
install VS on TFS server (http://geekswithblogs.net/jakob/archive/2010/05/14/building-visual-studio-setup-projects-with-tfs-2010-team-build.aspx)
Use 3rd party software on tfs
I do not wish to rely on 3rd party software or install vs 2010 on server as i have no licence to spare
Wix: http://wix.sourceforge.net/
It can be invoked using MsBuild.
I am using it quite successfully in one of my projects
This page gives some info on what is needed http://wix.sourceforge.net/manual-wix3/authoring_first_msbuild_project.htm
You should create the MSI Build package on TFS Build the same way you do it locally.
If you don't have anything yet, I strongly encourage you to look at Wix and use it. However Wix is mainly lowlevel package generation for MSI.
If you have complex needs for installation wizard you may rely on InstallShield to get the job done.
By using InstallShield (IS) you have two options:
Create a deployment project that will be 100% compatible with Windows Installer (the technology that builds .msi), no more no less. By doing that you can build your IS project pretty easily with Team Build.
Create a deployment project with the IS flavor (with a installation bootstrap) and you'll have to deploy the needed runtimes of IS in order to successfully build.
However I strongly encourage you to not choose the way you'll create your deployment package based on the Continous Integration constraints, if you have to install 3rd parties on your build agent, so be it, it won't be the toughest thing to do. (especially if those are VM you can clone)