More on the Orcas features for Team Build
Brian Harry posted a TFS roadmap. I'd like to expand on the portion that describes the features specific to Team Build. Keep in mind that these features can change before Orcas ships, so there are no guarantees that it will match what's described below.
Build
- Support multi-threaded builds with the new MSBuild.
- Continuous Integration – There are many components to this, including build queuing and queue management, drop management (so that users can set policies for when builds should be automatically deleted), and build triggers that allows configuration of exactly how when CI builds should be triggered, for example – every checkin, rolling build (completion of one build starts the next), etc.
- Improved ability to specify what source, versions of source, and other build properties.
- Improved extensibility of the build targets – such as ability to easily execute targets before and after each solution/project is built.
- Improved ability to manage multiple build machines.
- Stop and delete builds from within VS.
- .NET Object model for programming against the build server.
- Simplified ability to specify what tests get run as part of a build.
- The ability to story build definitions anywhere in the version control hierarchy.
There's a lot there.
The first item refers to the feature in msbuild where it spawns multiple processes to build projects in parallel, for projects that don't depend on each other.
Continuous integration is the flagship feature for Team Build in Orcas. There's a build definition dialog that lets you specify all of the build "metadata," such as the name, workspace mappings, location of the tfsbuild.proj file, the build agent (aka build machine), and so on. The workspace mappings for a build definition (called build type in v1) are stored in the database, so that we can efficiently determine which build definitions are affected by a particular check-in and thus need to be queued for building. The dialog allows you to select one of your workspaces to be used as the "template" for the build workspace.
Build agents are first-class objects in the system. A build agent encapsulates a computer name, port number, description, build directory, and status (enabled, disabled, unreachable, or initializing). Build agents can be added and removed as needed. When a build agent becomes unreachable or unresponsive, the error message is stored with the agent and is displayed in the GUI to aid in determining what went awry.
Every build goes into the queue for a build agent, and queued builds have priorities, can be postponed (paused), and removed from the queue. CI builds are queued with a version that specifies which version of the sources should be built.
Drop management is really about build management. You can specify build retention policies for a particular build outcome (failed, stopped, partial success, successful), and the policy controls how many builds should be kept (none, all, or a particular number). You can override the policy for a particular completed build and specify that it should be kept until it is deleted manually.
With CI you get the ability to build each individual check-in, or you can choose to accumulate checkins over a period of time such that builds start no more often than the number of minutes that you specify.
In items 3 and 4 we've really tried to address a lot of the feedback from users, including the MSDN forum. There are a lot more extension points in the targets file. You can have different targets executed before and after each project or solution, get separate log files for each project and solution, create workspaces spanning multiple team projects, specify additional msbuild switches when starting a build, experience better error reporting, and more.
The tfsbuild.proj file can be located anywhere in the tree, and all of the paths in it can be relative to either local or server paths, allowing it to work well with branch and merge (i.e., there are no branch-specific paths in the proj file).
Yes, you can stop and delete builds from inside Visual Studio. You no longer have to fire up the command line to do that.
With Orcas, Team Build gets an object model. Version 1 shipped with only the wsdl.exe-generated proxies.
The "simplified ability to specify ... tests" refers to the product version of the TestToolsTask enhancement I posted about earlier, which allows you to specify test "containers," such as assemblies, rather than having to use test lists (.vsmdi files).
There's a lot more that we want to do in the future. This is really just the beginning.
tags: tfs, team foundation, team build, orcas, continuous integration, msbuild, build
