Wednesday, June 07, 2006

VSTS workshop 2nd Ed

Exactly three months ago, Ana and I did the last VSTS two-day workshop. It was high time to repeat it. In the meantime, many important things happened - TFS released, a new Team Edition for DB Pros announced…
Therefore, we did it again– yesterday and today, with 18 people attending the sessions we even did a half an hour session on Team Edition for DB Developers using currently available information.

Designer and the source control
In the evaluation sheets at the end of the workshop, someone left an interesting question, asking whether there designer tools exist that integrate with the source control of the TFS. Had the person asked the question during the session, I would have answered that my understanding is that Expression Interactive Designer will support checking the files in and out, but apart from one sentence in one .ppt from the last year’s PDC I wouldn’t have much evidence to corroborate the statement. Do you have any?

Questions
What are the topics people were most interested in and wanted more coverage of:
  • custom check in policies (samples),

  • extensibility in general,

  • in depth source control usage strategies discussions (how to organize and how to work with the code),

  • custom events in general (we demoed a custom WorkItemChanged event handler, which was nice but obviously not enough :-);),

  • one custom event handler people particularly asked for, was a notification that would be send to interested parties as soon as a change in a specific code branch is checked in, so that they know that the change exists and possibly needs to be merged (see the share/merge story below).  

Lack of sharing functionality in Hatteras
As soon as we stated that there is a Source Safe functionality that is not supported in VSTS’s SCM, namely sharing, a member of the audience screamed – “But we need sharing! We can’t live without it!”
The arguments we gave, for VSTS not supporting Source Safe type sharing, were along the lines of this argumentation: in order to protect the consistency of the code it is much better to merge explicitly the changes from the common code on your own terms, than to get them automaticaly as soon as they are checked in. Surprisingly, this argumentation sufficed. :-)

WIT customization
As usual, we did a full demo of WIT customization, customizing the WIT’s xml definition directly. Only after doing everything by hand did we present the Process Template Editor by Joel Semeniuk. People certainly appreciated the ease of use of all UI way of editing the WITs using the editor. This editor is also a very useful learning tool for those that are just starting to play with WIT customization.

These two days were fun. The audience was very attentive and it was joy to present.

0 Comments:

Post a Comment

<< Home