Branching in TFS 2010 Part I (Branching Theory)

18,824 views

Published on

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

Published in: Technology
2 Comments
8 Likes
Statistics
Notes
  • It means never have the state where you are not allowed to change code, due to fear of breaking something prior to formal testing or a release. Instead, you continue work in a new branch.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • don't know what is meant by 'Never have code freezes'
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
18,824
On SlideShare
0
From Embeds
0
Number of Embeds
2,767
Actions
Shares
0
Downloads
0
Comments
2
Likes
8
Embeds 0
No embeds

No notes for slide

Branching in TFS 2010 Part I (Branching Theory)

  1. 1. Branching in TFS 2010 Part I by John Varan
  2. 2. Branching in TFS 2010: Part I…you need to develop just the rightamount of fear of branching. Thisdelicate balance seems to be verydifficult to find. Most people eitherhave too much fear or not enough.” ~Eric Sink
  3. 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. 4. Branching in TFS 2010: Part I A simple parent-child branch
  5. 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. 6. Branching in TFS 2010: Part ISome 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. 7. Branching in TFS 2010: Part I• Forward Integration – the act of merging changes from a parent to a child branch.
  8. 8. Branching in TFS 2010: Part I• Reverse Integration – the act of merging changes from a child to a parent branch.
  9. 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. 10. Branching in TFS 2010: Part I Branching can be tricky, and it does require some skill. Discipline is the key!
  11. 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. 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. 13. Branching in TFS 2010: Part I Branching Patterns• There are 3 primary patterns.• Each has several variations.• Hybrid patterns are also possible.
  14. 14. Branching in TFS 2010: Part I Release Branching• Two main variations: stairstep and mainline.• Simplest pattern• Least flexible
  15. 15. Branching in TFS 2010: Part I Stairstep Release Branching• Works on single release at a time.• New branch for each release.
  16. 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. 17. Branching in TFS 2010: Part I Mainline Release Branching• One main branch continues indefinitely• Each release branches off of it
  18. 18. Branching in TFS 2010: Part I Mainline Release Branching• Supports concurrent release development• Complex• Can require multiple test environments
  19. 19. Branching in TFS 2010: Part I Quality Branching• Usually has 3 separate branches• Changes are “promoted” from one to the other
  20. 20. Branching in TFS 2010: Part I Quality Branching• More flexible• Complex• Can require a dedicated person to manage branching
  21. 21. Branching in TFS 2010: Part I Feature Branching• Separate branch for each major feature• Very flexible
  22. 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. 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. 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. 25. Branching in TFS 2010: Part I Shared CodeHow 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. 26. Branching in TFS 2010: Part I Shared CodeInstead, 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. 27. Branching in TFS 2010: Part I End of Part IPart II: Our solution and how to configure and use itin TFS.

×