Question

I'm new to TFS and we're trying to automate the test / build / deploy process for our builds.

The problem I'm experiencing is that when I try to start a build with automatic deployment (for a webpage) using the MSBuild Arguments it complains that it doesn't have the necessary DLLs and I've figured out so far that they get installed with Visual Studio Premium or Ultimate, but then other people complained that something like Visual Studio shouldn't get installed on a Server =)

The TFS is also the build server for now and I'd like the know if there are any known requirements for these things to work:

  • Automated UI Testing
  • Automated deployment
  • Automated publish
  • Code Analysis

I'm working with TFS 2010 and Visual Studio 2010 (Premium). Any help, comments or different approaches are welcome =)

Was it helpful?

Solution

The way we handle that on my team is to actually check all the references needed to build the product in to source control. Anything beyond the .NET framework itself, and whatever you get for installing a build controller/build agent, gets checked in..

Positive bits:

  • Setting up a build agent is trivial (just "Install Server 2K8R2, install build agent, start building").
  • Don't have to worry about complicated SDK installation to match people's dev boxes.. References are all the exact version checked in to source control.
  • You get binary version control, which means if you need to do a maintenance release and build against last year's version of a particular API, it's super easy.

Negative bits:

  • Bloats your source control a bit
  • Feels weird checking binaries in to source control
  • Need to be very vigilant about maintaining structure and cleanliness of how you check in the binaries, otherwise it can easily get out of control

Beyond that, as far as making the test bits work from your build agent.. Probably the easiest way would be to install the test agent. The UI automation stuff in VS2010 is the "CodedUI Test" framework.. It extends the normal VS Unit Test framework, but requires some additional registrations to work.

More complicated, but super useful longer term is to set up the full "Visual Studio Lab Management" platform. Downside is, to fully leverage it you'll need to hook up a System Center Virtual Machine Manager server and at least one Hyper-V host, and build out a virtual machine with a "Clean" VM snapshot (everything except the product you're testing installed). Once all that's in place you get a really slick end-to-end build-deploy-test experience.. You trigger the product build via the build system, once that completes your environment is restored to that absolutely clean state (no worries about leftover bits from last version corrupting your testing, etc), the product gets published to this test environment, and then it executes your tests.

Not sure if you're using TFS for workitem tracking, testcase management, project planning, and whatnot.. If not, the lab management stuff may be too heavy-weight to mess with. More info here if you're interested in messing with that part. :)

OTHER TIPS

Your build server needs the appropriate versions of Visual Studio. For instance, if you want to do database unit tests, then the build server needs VS Ultimate to be installed.

If there's an issue with having "client" software installed on a server, then use a separate build server. It makes perfect sense for a build server to have the necessary tools installed to perform builds.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top