A look at some of the problems introduced by feature branches, and a short introduction to using Branch by Abstraction as an alternative.

1. Branching Strategies
Chris Birchall
2013/06/21
#m3_dev

2. Branching strategies
Feature Branches
vs
Branch By Abstraction

3. Feature Branches
● master branch is used for rollouts
● Little work done directly on master
● For every feature/bugfix, cut a branch
● To rollout a feature, merge to master
master
feature A
feature B

4. Feature Branches: Problems
Merging is HARD WORK

5. Merging is HARD WORK
Sometimes impossible for git/svn to auto-merge
master
feature A
feature B
BOOM!

6. Me
class
FooService
interface
FooService
class
DefaultFooService
class
CachingFooService
changed class to interface
Other dev
class
FooService
● altered a bunch of existing methods
● added a bunch of new methods
BOOM!
Real life example (happened last week)
Took over an hour to merge manually

7. Feature Branches: Problems
Merging is SCARY

8. Merging is SCARY
Do you trust your tools to merge correctly?
Have had problems with buggy tools (e.g. git-svn)

9. Feature Branches: Problems
Merging is A CHANGE
to the codebase

10. Merging is A CHANGE to the codebase
Merging counts as a change to the codebase
→ Need to perform manual tests before rollout
End up doing same tests before and after merge

11. Feature Branches: Problems
Feature branches are not
subject to CI

12. Feature branches are not subject to CI
Jenkins is only working against master
Manually creating a job per feature branch is silly
Can automate it, but it's complicated and brittle

13. Feature Branches: Problems
Feature branches go ROGUE

14. Feature branches go ROGUE
Branch can diverge massively from master
Becomes impossible to merge safely
Branch lives for weeks, months, ...

15. A solution?
Branch by Abstraction

16. Branch by Abstraction
The name is misleading...
Using B by A, we DON'T BRANCH!
NO BRANCHES == No MERGING

17. Branch by Abstraction
● All dev is done on master
● Incomplete work is disabled using feature flags
● master is always stable, ready for rollout
● Changes performed by introducing abstraction

18. Making a change using B by A
1. Add abstraction layer around the code you want to
change. (Extract interfaces, etc.)
2. Add the new implementation, but keep using the
old implementation in production.
3. Flip the switch! (Update flags, switch Guice modules, etc.)
4. Remove old implementation if no longer needed

19. Example: Switching to a new auth API
1. Refactor concrete class LoginService into
interface + impl class
class
LoginService
interface
LoginService
class
LegacyLoginServic
e
Update surrounding code to use LegacyLoginService
(Maybe add a factory to provide the implementation?)

20. Example: Switching to a new auth API
2. Add new implementation (+ unit tests, of course!)
interface
LoginService
class
LegacyLoginServic
e
Add feature flag to allow switching between implementations in
test environment
interface
LoginService
class
LegacyLoginServic
e
class
NewLoginService

21. Example: Switching to a new auth API
3. Flip the switch!
Update the value of the feature flag in production

22. Example: Switching to a new auth API
4. Remove old implementation
interface
LoginService
class
LegacyLoginServic
e
interface
LoginService
class
DefaultLoginServic
e
class
NewLoginService
Refactor (change class names, etc.) if necessary

23. Example: Switching to a new auth API
Finished!
Remember:
● All this happened on master
● Codebase was stable throughout the process
● Both new and old impls were subject to CI
● No merging!

24. Branch by Abstraction: Prerequisites
● Reasonably good, modular codebase
○ Easy to introduce abstractions
● Good devs!
○ Can be trusted not to break the build
● A good suite of unit tests
● A feature flag system
○ Ideally, well-integrated with toolchain
○ e.g. enable features using checkboxes in Jenkins

25. Thank you!
Further reading:
http://paulhammant.com/blog/branch_by_abstraction.html/