Not every team uses TFS for both source repository and build automation, even in Microsoft.  Some teams maintain their custom build tool (a.k.a “manual build”) which means the build information is not tracked by TFS, but at the same time they want to use Test Manager or import test case results into TFS.  In order to keep things consistent, it is necessary to have a build record TFS for the manual build.  For instance, we may want to know what build is used for producing a test run.

Programmatically, this can be done by IBuildDefinition.CreateManualBuild API.  If you don’t want to write your own code, you may use TFS IP to do this.

Since a build record must be associated with a build definition, we have to create a build definition in the team project using Visual Studio:

image

This does not need to be a completely valid build, since it’s for tracking purpose.  For instance, you can leave the “Items to Build” in Process tab empty, it will be fine.  Suppose it is called “Manual_Build” in Sandbox team project.  Now we want to create a manual build with build number “Custom Build 1.2.3.4 20120508”, then create a runbook and drag “Create Manual Build” to the workspace:

image

There are also some optional properties in this activity.  You may choose whatever relevant to your project.

image

Note that the service account user has to have the permission to “Update build information”,

image

Once the runbook is executed, the new build record will be created and be visible in Visual Studio:

image

When you test the runbook, remember that the build number has to be unique in all build definitions.  Even a build is deleted, the record in the database will still have the build number and there is no way to change it.  So don’t use the same build number in the testing as the one you would use in the production run.  Have fun!