@RyanKnuth:Thanks for the tip - that shortcut works beautifully!
Say I'm working on a project that has a certain build process in place and it gets shipped, the code will be branched and I'll carry on working on the main trunk. If I needed to fix a bug in the earlier branch of the code, I would want to be confident that any build I perform against it was the exact build process that was around when the branch occurred. (You could kind of do this in team build 2008 by storing the build script within the workspace of the solution)
The build processes I've been involved in do more than just build the solution, they also package and in some cases deploy the application binaries, as well as upgrading databases. It would seem to me that these "processes" fit better with the new build workflow you demonstrated, but if they are "global" build definitions and not tied to a specific branch of the app, then I'd still have to use my current msbuild approach.
Is there any way in team build 2010 to "branch" these build processes? If not, how would you recommend branch builds be maintained?
I really like the unified pipeline - I can think of several examples of when this would have been really useful in projects I've worked on in the past.
The mix of screen capture and video presentation is nice too - job well done!
I didn't realise the lead singer from Weezer worked at Microsoft!