5

I have a TeamCity build server, with about 20 "build agents", both Windows and MacOS machines.

Often, I need to install a newer version of XCode or VisualStudio or some other tool. Having to do this on all machines manually is boring and error prone. I'm trying to find out what is the best way to achieve the following:

  • make it easy to change a system configuration, without having to do it on all machines manually.
  • make it easy to add a new machine to the group.
  • ensure the machines are as identical as possible

The jobs these machines are executing is relatively heavy, fully consuming 8 cores, and be very heavy on IO. It's fine if the solution includes spending money.

Lucas Meijer
  • 63
  • 5
  • Where do the virtual machines in the title come into play? – MDMarra Jul 23 '10 at 22:42
  • I've been assuming the best solution would include virtual machines, as they can expose identical virtual hardware on all machines. Maybe that assumption is incorrect though – Lucas Meijer Jul 23 '10 at 23:20

3 Answers3

3

http://www.puppetlabs.com/

I am not sure on the extent of the windows support, but the FAQ does mention basic windows support in the most recent version. This tool would be perfect if we were talking Linux, so if the windows implementation is comparable it would probably be perfect. As for the Mac machines, they are BSD based, so you could probably use the Linux side of puppet with those as well.

I've done similar things to what you mention with Linux using Puppet. In puppet you build a site policy through declarations of how things should fit together. In a normal setup you have a Puppet master with the site policy which get's polled at a frequency from the puppet workstations\machines. The "puppets" look at what requirements they have met, and then get told what they should do by the Puppet Master's policy. Rolling updates would be a simple modification of the policy on the Puppet Master, but take this with a grain of salt. I do not know the extent of the windows functionality.

Another popular one is CfEngine: http://www.cfengine.org/

http://novosial.org/cfengine/windows/

http://novosial.org/cfengine/macosx/

I haven't used CfEngine, but it is quite popular.

user1204270
  • 183
  • 1
  • 7
Joshua Enfield
  • 3,404
  • 8
  • 41
  • 58
1

There are a few directions you could go with this. It'll depend on the infrastructure you have in place, and the software you're willing to pay for and/or deploy.

What's the purpose of having so many separate build machines? Is it to keep code projects isolated from each other, or to maximise build speed with additional resources? Or are the build machines actually the client workstations on your network, which are used for additional purposes other than building?

If it's to keep the build environments isolated, then virtualisation is a good route to persue. You'll be able to raise your 20 build machines as individual VMs without the extra hassle of purchasing/configuring hardware for each one.

On the other hand if it's for performance scaling, bundling the build machines onto VMs doesn't make as much sense since VMs on a host contend for that host's CPU, RAM and disk availability. You're better off adding the max amount of CPU cores, Gbs RAM, and disk spindles as required by adding additional units of hardware.

As for the requirement to update software packages across all machines: - For unified software management across a number of Windows machines without requiring a re-deployment of the OS, check out Microsoft's System Center Config Manager, and System Center Essentials. They sound about right for your requirements: http://www.microsoft.com/systemcenter/en/us/products.aspx - For whole-system deployment where you'd make a change to a system 'image', then re-deploy that image out to your build machines, you can do this with VMs using features built into whichever virtualisation product you're using - 'Templates' on ESX or Hyper-V. Alternatively, you could look at a PXE-boot build solution like Windows Deployment services.

Whichever way you go with this, your biggest pain-point is likely to be the mixed use of Windows and MacOS for your build machines. A standard OS across all of them is pretty much a pre-requisite for being able to update them all in a unified manner.

EEAA
  • 108,414
  • 18
  • 172
  • 242
Chris Thorpe
  • 9,903
  • 22
  • 32
  • The reason to have many buildmachines is speed, not consolidation/isolation. The only reason I was thinking VM is that they can expose a single hardware environment on multiple machines. I can deal with seperate solutions for OSX machines, and for windows machines. the machines are dedicated build machines. – Lucas Meijer Jul 26 '10 at 10:02
1

A product similar to Acronis Snap Deploy would let you rollout updates to your IDE etc. without too much headache. You can customise the build for specific endpoints too, so you can preload device drivers but there's no compatibility with OSX (you could try getting it running off of Boot Camp or something though).

If you had the time to fiddle a little bit you could try a free solution like WPKG.