Friday, May 09, 2008

Video showing the Windows Workflow Foundation being used to build a Build in "Rosario"

Team System Rocks - Version Control and Build Mini-Story - Part 2 - Build

"Version Control and Build Mini-Story - Part 2 - Build"

Mickey Gousset presents Part 2 of a "Rosario" (aka Team Foundation Server vNext) mini-story screencast, focusing on building the Build using the new coolness that's coming in "Rosario"... (Distributed builds, workflow, etc)

I think the coolest part is how the TFS team is dogfooding the Windows Workflow Foundation (WF).

Sure WF is in SharePoint 2007, but IMHO, WF has been kind of the red headed stepchild of the .Net 3.x wave. While it was probably the most "cooked" of the three tech's (WPF, WCF, WF) at release (with solid tooling in place, etc), it seems to have been the least talked about.

WF has the same potential of change as does WCF & WPF, yet it hasn't really caught on yet. Why? Because it's kind of hard for us (Dev's) to wrap our heads around. Where do you host it? Where does it run? Is this a thing which we run stuff through or something run on stuff? How do I let the true business user build a workflow without giving them VS? How do I wrap all this into my app? How do I move my code into a workflow? Store, version and deploy it? etc, etc, etc.

Presentation change (WPF)? Pretty easy to get the general idea as, from the highest level, it's an enhancement of something we already have and do. Communication change (WCF), again we already do communication, WCF makes it much easier, so again from a high level, easy to understand.

Workflow? That's another beast. It really requires a change in mindset. While from the highest level, almost every app has a "workflow", trying to wrap your head around a brand new way to separate the workflow from the app is what I believe is the hardest part of "getting" WF. We're so used to writing the workflow code into our apps, it is so natural and basic, that using WF is like learning to walk on the moon... taking a basic process and changing it's base rules and assumptions...

Anyway getting back to my main point, by baking WF into the TFS Build process, I think the TFS team could invigorate interest in WF. Dev's will see this, use it and say, "Wow, I want my app to do this... " Once we get comfortable with it, use it day to day, one of the bigger barriers to WF will begin to crumble...

 

Also check out Part 1 for an insight into the Version control changes coming as well as his other Rosario videos...

No comments: