Branching for CD? Think Again!

1. Copyright © 2015 SolutionsIQ Inc. All rights reserved.
Branching for CD?
Think again !
Devesh Chanchlani

2. Self Introduction
• Passionate Programmer
• Technical Agile Coach with SolutionsIQ
• Coach teams to embrace, scale and sustain
XP practices
• Belong to Pune

3. 3
Traditional Branching Strategies

4. Long Lived Feature Branches
4
Less risk of non-finished
changes
» Merging with other
Feature branches
» Merging with mainline
changes
» Accommodating
Refactorings and design
improvements

5. 5
Changes being made to the
mainline after being reviewed
» Merging issues
» Refactoring becomes
challenging
» Cannot have CI for each
branch
» Sometimes changes are big &
individual commits not stable,
that folks simply squash their
changes into big commits.
Short Lived Feature Branches
D1
D2
D3 D4

6. Another Curious Case
6

7. <Footer Content: Presentation Title, Partner Name, Other> 7

8. 8
“Feature branching is a poor man's modular architecture,
instead of building systems with the ability to easy swap in
and out features at runtime / deploytime they couple
themselves to the source control providing this
mechanism through manual merging.” Dan Bodart

9. Trunk Based Development (TBD)
<Footer Content: Presentation Title, Partner Name, Other> 9

10. What it means …
 All developers commit to a single branch,
called trunk, making frequent check-ins.
 Branches are created only for Release
purpose.
 Bugs are always fixed on trunk and then
merged with release branch.
 Regular developers don’t commit to a release
branch.
 Release branches are never merged back to
trunk.
 Release branches are short-lived, frequently
being replaced by other release branches.
10

11. 11
Trunk Based Development Strategies

12. 12
Imagine you are releasing into production every two
weeks, but need to build a feature that's going to take
three months to complete. How do you use Continuous
Integration to keep everyone working on the mainline
without revealing a half-implemented feature on your
releases?

13. Feature Toggles
13
Courtesy: Spotify Labs / Henrik Kniberg

14. Feature Toggle implies …
14
 A configuration file defines a bunch of toggles for various pending features.
 These toggles are mostly applied at UIs, from where interaction with the
features begins.
 For features with no UI, the toggle will be in the app code.
 In such cases, techniques like polymorphic substitution and dependency injection
should be used to avoid crude conditional tests.
 Feature toggles should be removed once the feature is complete.
 Pipelines for different permutations of toggles for releases should be setup.
 If either of the build fails, it implies a bad commit.

15. Feature Toggle types
15
1. Release – partial features, temporary
2. Business – certain class of users, permanent
3. Runtime – easier rollbacks, run tests with various configurations of
features
4. Build – new feature codebase is not compiled

16. Branch by Abstraction
16
Consumer
Component to
be replaced
STEP 1
Consumer
Component to
be replaced
Abstraction
Layer
STEP 2
Consumer
Old
Component
Abstraction
Layer
New
Component
STEP 3
Consumer
Old
Component
Abstraction
Layer
New
Component
STEP 4

17. 17
TBD Success Stories

18. Facebook's Trunk Based Development
18

19. Google’s Scaled TBD
19

20. Google’s Scaled TBD
20
 Deals with enormous codebase which changes at enormous speeds.
 Provides extensive tooling to the developers like
 Pre-commit validations
 formal integration/merge/commit itself
 have a “Distributed Builds” capability, which
 Supports “Caches” for leveraging results from previously built modules
 Uses “Gerrit“ for code reviews on refs/for/master branch.
 Has decided owners for all modules.
 Third party dependencies can have only one existing version in the trunk.
 Releases are made from branches cut from the trunk

21. Google’s Scaled TBD
21
Master
Canary
Beta
Dev
Stable

22. What it takes to Deliver Continuously
22

23. References
 Paul Hammant - http://paulhammant.com
 Martin Fowler - http://martinfowler.com/bliki/FeatureToggle.html
 Carlos Lopes - Multiple projects, different goals, one thing in common: the
codebase!
 Henrik Kniberg – Engineering at Spotify
 Chuck Rossi – The Facebook Release Process
23

24. Our Customers
24

25. 25
Thank you!
solutionsiq.com