Part I of a presentation about branching and merging strategies in TFS 2010.

1. Branching
in
TFS 2010
Part I
by John Varan

2. Branching in TFS 2010: Part I
…you need to develop just the right
amount of fear of branching. This
delicate balance seems to be very
difficult to find. Most people either
have too much fear or not enough.”
~Eric Sink

3. Branching in TFS 2010: Part I
Branching is like creating a
parallel universe.
• A branch is a child universe spawned off the main
(parent) universe.
• The child universe evolves independently.
• Branching is for ISOLATION

4. Branching in TFS 2010: Part I
A simple parent-child branch

5. Branching in TFS 2010: Part I
Why do you need branching?
Have you ever…
• needed a code freeze?
• wanted to know what code was included in a release?
• wanted to avoid releasing code that wasn’t ready?
• wanted to allow developers to have an experimental
playground?
• found yourself putting everything on hold for refactoring?
If you answered yes to any of these, you need branching!

6. Branching in TFS 2010: Part I
Some basic branching terminology:
• Main Branch – the primary branch that all changes are
eventually merged into. Also known as the trunk or
mainline branch.
• Development Branch – contains all active development.
In many scenarios, it’s the same as the main branch.
• Release Branches – each release of a product should
create a new branch, as a child of the main branch.

7. Branching in TFS 2010: Part I
• Forward Integration – the act of merging changes from a
parent to a child branch.

8. Branching in TFS 2010: Part I
• Reverse Integration – the act of merging changes from a
child to a parent branch.

9. Branching in TFS 2010: Part I
• Baseless Merge – the act of merging changes from one
branch to another, where the two branches are not in a
parent-child relationship.

10. Branching in TFS 2010: Part I
Branching can be tricky, and it does
require some skill.
Discipline is the key!

11. Branching in TFS 2010: Part I
Five Keys to Making Branching Successful
• Stick to correct process, even if it seems trivial.
• Avoid branches off other branches, if possible.
• Merge with Forward and Reverse Integration often.
• Do not confuse branching with shelving.
• Never have code freezes.

12. Branching in TFS 2010: Part I
Seven Signs Something is Wrong
• Merging is put off to the end.
• Merging happens too often.
• Merging never happens.
• Purpose of a branch isn’t clear.
• You find yourself having to halt development efforts.
• Branches are used to isolate developers instead of code.
• A change is merged to an older release.

13. Branching in TFS 2010: Part I
Branching Patterns
• There are 3 primary patterns.
• Each has several variations.
• Hybrid patterns are also possible.

14. Branching in TFS 2010: Part I
Release Branching
• Two main variations: stairstep and
mainline.
• Simplest pattern
• Least flexible

15. Branching in TFS 2010: Part I
Stairstep Release Branching
• Works on single release at a time.
• New branch for each release.

16. Branching in TFS 2010: Part I
Stairstep Release Branching
• Requires least amount of branching
• Not very flexible
• Can require multiple test and build
environments

17. Branching in TFS 2010: Part I
Mainline Release Branching
• One main branch continues indefinitely
• Each release branches off of it

18. Branching in TFS 2010: Part I
Mainline Release Branching
• Supports concurrent release development
• Complex
• Can require multiple test environments

19. Branching in TFS 2010: Part I
Quality Branching
• Usually has 3 separate branches
• Changes are “promoted” from one to the other

20. Branching in TFS 2010: Part I
Quality Branching
• More flexible
• Complex
• Can require a dedicated person to manage
branching

21. Branching in TFS 2010: Part I
Feature Branching
• Separate branch for each major feature
• Very flexible

22. Branching in TFS 2010: Part I
Feature Branching
• Most flexible
• Complex
• Can require separate test environment per
feature (but there’s a workaround)

23. Branching in TFS 2010: Part I
Agile Development
• Shouldn’t make a difference whether you use
Agile or not
• But it does…
• When do you run continuous builds?
• Which branches cause continuous builds?

24. Branching in TFS 2010: Part I
Agile Development
• Feature branching (or a hybrid of it) is most
suitable for Agile
• Feature branch = story branch
• Continuous build tied to main branch only, not
to each feature branch

25. Branching in TFS 2010: Part I
Shared Code
How to handle shared libraries and code?
• Many ways to solve this problem
• Sharing the actual source isn’t ideal
• Complicated
• Problematic with automated builds
• Inflexible

26. Branching in TFS 2010: Part I
Shared Code
Instead, share the compiled binary assembly.
• Shared library is a separate project
• Compiled assembly stored in TFS
• Versions of compiled assembly are branched into
the “Lib” folder of a referencing project

27. Branching in TFS 2010: Part I
End of Part I
Part II: Our solution and how to configure and use it
in TFS.