This post is part of a series on TeamBuild 2010:
- TeamBuild 2010 : Architecture overview
- TeamBuild 2010: Build definitions new features
- TeamBuild 2010 : Gated Check-in and Private Build
It’s time i get back to my presentation of TeamBuild 2010 new features
Since TeamBuild is now based on Workflow Foundation 4.0 Microsoft has provided some activities specifically for TeamBuild. Those activities are like the Task in TeamBuild 2008 :
As you can see from the previous screenshot there are two main categories: one for build activites and one for LabManagement activities. In this post i’ll only talk on the first one.
The first activities to know are the one defining sequences:
As i explain in the first post of this series the build process is now executed on a build controler and on a build agent. The AgentScope sequence is here to indicates to the build engine that all it’s activities are to be run on the build agent. The InvokeForReason sequence can be use to specify a set of activities to run depending on the current build type. To do this, the InvokeForReason activity exposes a enumeration parameter which can have one or more of the following value indicating which build type should execute the sequence:
- None: the sequence is never executed.
- All: the sequence is always executed.
- BatchedCI: build configured as “Rolling build” (continuous integration with check-in accumulation).
- CheckInShelveset: build configured as “Gated Check-in” (build on a shelveset before checkin).
- IndividualCI: build configured as “Continuous Integration” (build at each checkin).
- Manual: build configured as “Manual”.
- Schedule: build configured as “Schedule” and who was triggered because an change append.
- ScheduleForce: build configured as “Schedule” and who was triggered without any changes.
- Triggered: same as selecting BatchedCI, CheckInShelveset, IndividualCI, Manual, Schedule, ScheduleForce and UserCreated.
- UserCreated: i’m still looking at how to trigger this type of build
- ValidateShelveset: any build not configured as “Gated Check-in” and launch manually while specifying a shelveset. This is a Private build.
The last sequence, SharedResourceScope, can be use to execute some activities using synchronization based on a resource. This is like using a lock in csharp to synchronize access to a resource.
The next category of activities we can find are activities to manage Workspaces:
- ConvertWorkspaceItem: converts a server path ($/server/…) to a local path or vice-versa based on a workspace mappings.
- ConvertWorkspaceItems: same asConvertWorkspaceItem but accepts a collection of paths.
- CreateWorkspace: creates a workspace on the local machine using the current build definition.
- DeleteWorkspace: deletes a workspace.
- GetWorkspace: returns a workspace definition.
- RevertWorkspace: cancels all updates on a workspace.
- SyncWorkspace: synchronizes a workspace locally. All modifications are accessibles (new items, deleted items and updated items).
Those activities provides about all we need but we can regret the absence on an activity to create a workspace which is independant of the current build. (The CreateWorkspace activity is internally coupled to a build execution to gets the build definition).
You can find activities to manage labels:
- LabelSources: creates a label on the specified files.
- LabelWorkspace: creates a label on all the file of the specified workspace.
There are some activities for FileSystem management:
- CopyDirectory: copies a directory.
- CreateDirectory: creates a directory.
- DeleteDirectory: deletes a directory.
For working with files, we only have activities for search and download from the source server:
- DownloadFile: downloads a file for the source server.
- DownloadFiles: download a collection of files from the source server.
- FindMatchingFiles: gets all files matching the specified template.
We miss some activities for basic file management like copy, move, create or delete.
Most of the other activities are for build management and build information:
- AssociateChangesetAndWorkitems: associates changesets and work items to the build (same as in TeamBuild 2008).
- CheckInGatedChanges: checkin the modifications which triggered a “Gated Check-In” build.
- EvaluateCheckInPolicies: evaluates all checkin policies on the specified workspace.
- GetBuildAgent: gets the current build agent. This activity only returns a value if called in an AgentScope sequence.
- GetBuildDetail: gets the build details for the current build. (Build agent, build definition, status, …)
- GetBuildDirectory: gets the build directory of the current build for the build agent and expands all variables using the current context.
- GetBuildEnvironment: gets the current environment (build controler or build agent) and the custom assemblies path.
- GetTeamProjectCollection: gets the current build Team Project Collection.
- MSBuild: launches the msbuild command.
- OpenWorkItem: create a work item (any type).
- SetBuildProperties: updates the build detail properties. (Build number, compilation status, drop location, source version to get, …)
- TfsBuild: launches a build using a TeamBuild 2008 build project. This activity is used when upgrading from TFS 2008 to TFS 2010 so that you don’t have to recreate all you customized (or not) builds
- UpdateBuildNumber: updates the build number based on the specified format.
Since tests have become first class citizens in TFS 2010 and VS 2010 we have some activities related to them:
- GetImpactedTests: gets the code which changed from the previous build and the impacted tests.
- MSTest: launches the mstest command.
Small new feature in TeamBuild 2010, the management of source indexing (updating symbol files to add path to sources in TFS) and symbol server:
- IndexSources: indexes the sources with a TFS path (item path and changeset number).
- PusblishSymbols: publishes the symbol to a symbol server.
With those two activities, no more need for the Windows Debugging Tools and some nasty customization of your build projects
The last activities are for logging:
- WriteBuildError: logs an error.
- WriteBuildInformation: logs an information.
- WriteBuildMessage: logs a message.
- WriteBuildWarning: logs a warning.
Thats all folks
The new engine based on Workflow Foundation 4.0 is really good and Microsoft provided a lot of activities but i’m a little disappointed that they only shipped those activities necessaries for their own build templates and that some activities are too tightly coupled to a build environment. But i’ll still say to Microsoft: “Good job, TeamBuild 2010 is really great !”
About SyncWorkspace, is this also used to check in changes when the build process changes the contents of a file. For example, my build process changes the contents of AssemblyInfo.cs to update the version. I would like to be able to check those changes back into source control. Can I use Syncworkspace to do that?
No SyncWorkspace is only one way : Server -> Client. There is no standard activity to make a checkin, you’ll have to write one.
We have a website, not a solution (no project files). All we need to be able to do is have a step which automatically copies all the files from TFS to a URL which is our dev server. For the life of me I cannot find a single resource anywhere that explains how to do this incredibly simple task. CopyDirectory seems to only work off a build output which our website has no build out. Any suggestions?
The simpliest solution would be to create your own workflow using the following activities :
* DownloadFiles to get your files from TFS.
* CopyDirectory to copy those files from one directory to an other.