Willy's Reflections - Visual Studio ALM Rangers

| Willy-Peter Schaub | Visual Studio ALM Rangers | In search of IT simplicity, quality and tranquility |

ALM Rangers Visual Studio 11 Readiness – Part 2: A small peek at the upcoming TFS Branching and Merging Guidance

ALM Rangers Visual Studio 11 Readiness – Part 2: A small peek at the upcoming TFS Branching and Merging Guidance

Rate This
  • Comments 13

This is part to an exploration of the upcoming ALM Rangers solutions for Visual Studio and Team Foundation Server 11. Previous posts:

In this post we are taking a look at the  Branching and Merging Guidance.

imageP7290334

Bill Heys is cooking (merging) a phenomenal solution as usual Smile

Abstract

This project delivers insightful and practical guidance around branching and merging with Visual Studio Team Foundation Server. The new release introduces new scenarios, consolidation of existing guidance and a new diagram style as shown below.

Epics

The Epics addressed by the solution include:

  1. I would like to understand the impact of Dev11 on branching and merging
  2. I would like to understand how long to wait with check-ins and merging (reverse integration)
  3. I would like to understand how to merge efficiently between parallel development teams that share a code base
  4. I would like to understand the security on branches and roles that impact branching and merging

What’s new?

In previous versions of this guidance, the branching diagrams used color to distinguish branch types (for example, MAIN was always green, Development was always red, Servicing Branches were orange, and the RTM or RELEASE branch was black as shown in the following diagram on the left <=

image image

In the new guidance the team is changing the color scheme of the diagrams. They will use colors AND labels to distinguish the versions of code being worked in each branch, as shown in the diagram above on the right => … why? We hope this new color scheme will be more useful and intuitive. For example, in the diagram above (on the right) there are four colours used to depict four versions of code, the latest shown in purple.

Another new example:
image

 

What do you think? Is the new diagram colo(u)ring style more practical and intuitive?

  • The new coloring only makes it more confusing. See here: http://i.imgur.com/F2Sn0.png

  • I've never liked the colors....It makes it hard to quickly understand and any good diagram shouldn't need a legend.  The coloring also means that printing the diagrams is really costly. Why can't you make the colors feel like RSA Animate (www.youtube.com/watch) and use whiteboard marker colors. Also the images look TOO polished and inflexible. Could you guys do them in a sketch feel like this: blog.accentient.com/.../WouldYouCouldYouWithTFS.aspx.

    Branching is meant to be flexible and the diagrams make them feel like they have to be rigid and inflexible.

  • Great feedback Allen. It is important to emphasize that what I am sharing is ALPHA content, so the team is looking for candid feedback and that changes are probable :) If, as your graphic indicates, you are confused by the background colour of the comment boxes then you will be glad to hear that the team is already considering a neutral colour or no colour at all for the comment boxes. Another suggesstion is to make all text black, with just  branches and nodes having a colour.

  • @Allen - Would it help if they followed UML notation and all looked more like yellow stickies?  This would clearly identify this information as supplemental or call-outs.

    @Willy While more cluttered than the previous version, I do like the way the new diagrams more directly walk you through branching across multiple iterations (or releases) of the product. I would agree with Allen that the current color scheme of the notes is confusing.  Also, Shawn's idea is definitely intriguing...

  • Have you guys considered making the diagrams live with real data showing how TFS works.

    Why can't you use the Branching and Merging Visualization features built into the TFS Product (blogs.msdn.com/.../Mature%20Track%20CS%2010-26-2009%201-16-38%20PM_thumb.jpg) or why aren't you using the DML diagrams that are in the VS Ultimate Product (blogs.msdn.com/.../directed-graph-markup-language-dgml.aspx)?

    If you want to be artistic why not use Gource? code.google.com/.../Screenshots

    And or if you really want to help the community surely you could create a data driven VISIO diagrams see here: www.microsoft.com/.../details.aspx

    Creating YADLT (Yet another Diagram Language/Taxonomy) is a waste of resources.

  • I've always wondered why the diagrams call out "create the SERVICE PACK, HOT FIX, and RELEASE branches at the same time." but the lines are drawn sequentially

    (one after another) as if to indicate that they are created at different points in time. I never liked the circles and square icons for branches and labels. Would be interested to see a METRO iconography/METRO style diagram.

  • I want diagrams to consistency show 4 releases....2nd New diagram only shows 2 Feature and 2 Version. :(

    Now....1 Versions isn't clear enough. 2 Versions cannot show how to repeat steps. 3 Versions shows different ways and I do not like. 4 versions shows patten & is clear & is Best Practice over Mutli-Release/Sprint/Many Months.

    Please show 4 always.

  • Our Developers are not clear on REVERSE Integrations and FORWARD Integrations....the merge txt with the small arrow looks hidden. Improvement would be to include full text: REVERSE Integration...FORWARD Integration plus larger arrow symbol.

  • Ramesh: Thanks for your feedback. We will attempt to make this clearer. We may need to use RI (for Reverse Integration) and FI (for Forward Integration) simply becuase of space limitations. We may also add a comment to indicate that FI is always a merge from Parent to Child while RI is always a merge from Child to Parent.

  • Narendra: Thank you for you feedback. We sometimes need to limit our diagrams for space reasons. I would suggest a compromise: Where a process or pattern is repeated in the same identical way, three repititions should be sufficent to convey the repetive pattern. A fourth repetition (version) should not add any clarity and may make the overall diagram too confusing.

  • Edwin: Thanks for your feedback. Perhaps you could provide an example of the METRO iconography / diagram style that you prefer. As for the way the lines are depicted, it is not possible to branch three branches in a single operation, so there is a sequencing to how these branches are created. The point is that you would branch Main -> Service Pack (or Servicing) and immediately branch Service Pack -> Hotfix, and then immediately branch HotFix -> Release. Logically it is "at the same point in time", but technically they are three sequential operations.

  • To all who suggest an alternative style or tool for creating these diagrams, we appreciate your suggestions. However, we have invested a lot of time using PowerPoint to create the diagrams. While we may consider changing tools, it is unlikely at this time. We are attempting to depict patterns for branching and are not attempting to use live or data-driven diagrams. As for why we don't use Gource - well the answer is simple, I work for Microsoft. I use Bing for search. :)

  • Bill, thanks for your feedback and for driving the branching and merging guidance solution with such passion.

    While the use of data driven, animated and VS based diagrams may sound appealing, we chose PowerPoint to enable the community to re-use the diagrams, especially in their own PPTX presentations. We could consider a more sketchy look and feel when we start creating Channel9 videos that walk the user through the scenarios?!?

Page 1 of 1 (13 items)
Leave a Comment
  • Please add 1 and 7 and type the answer here:
  • Post