2. Self Introduction
• Passionate Programmer
• Technical Agile Coach with SolutionsIQ
• Coach teams to embrace, scale and sustain
XP practices
• Belong to Pune
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
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
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
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?
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
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
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