A while back an announcement was made that TFSPreview.com had been made available for general testing. Various bloggers at Microsoft put an invitation token in their MSDN blogs so everyone can have a go at it.
In this article series we’ll take a very quick look at what the hosted TFS solution by Microsoft looks like.
Articles currently in the series:
[blockquote]Part 1: Getting Started
Part 2: Connect your development rig
Part 3: Configuring a Build server to work with TFS preview
Part 4: Connect your project to TFS and create a build definition (this post)[/blockquote]
Steps to hook up a project to your new build server
This article obviously assumes that you’ve already followed along with the previous articles and hooked up a build configuration for your TFSpreview account. Now we’ll take a look at how we can get our projects hooking up in a CI/Automated Build scenario with Team Foundation Services.
The steps from this point onwards are basically the same as if it would be an on-premise TFS server in your own domain. Your build server is configured, your code is hosted in TFS and all you’ll need to do is connect your project to the actual TFS and then create a new build definition.
Create a new project (or connect an existing one) and connect to TFS
Create a new build definition
At this point (if you’ve followed the articles in this article series) you should have a TFS server, a connection from Team Explorer to your TFS server and also a new project hooked up in your repository. Now its time to create our first build definition so we can automate the builds and deployments.
Move on to the "Build Defaults" tab. You’ll need to specify a build controller (you should have one here since we created one in the previous article). You will also need to specify a drop folder, where your binaries are going to be delivered upon the build:
Move on to the "Process" tab. This is where things get really interesting. You can from this dialog specify a variety of different variables for your project when it builds. I’m not going to dig into details here because my good mate Chris O’Brien have covered all of that in his article series about automated builds.
Test the build configuration
In order to validate that our setup now works with TFSpreview.com and our own build server and to validate our newly created build definition, simply make some changes to your project and check it in and have it automatically schedule a new build (We chose Continuous Integration, which will build on each check in). You can see that the build is now scheduled and currently running:
Voila. Build seems to be working.
This post was intended to give you an overview over the simplicity of creating a simple build definition and getting started with automated builds in TFSpreview (hosted Microsoft TFS). Pretty neat and it seems to be working just the way we want.
Obviously there’s some apparent questions like:
- What if I want to output my .wsp files as well?
- What if I want to execute a specific script upon the execution of the build so I can automate test-deployments?
- Etc. etc.
My first recommendation is to visit Chris O’Brien and read all the posts in his CI/automation series which is simply amazing.