Branching Strategies: Feature Branches vs Branch by Abstraction
8 likes22,777 views
The document discusses branching strategies in software development, comparing feature branches with 'branch by abstraction.' It highlights the challenges of merging feature branches, such as complexity, testing requirements, and potential for divergence, and proposes branch by abstraction as a solution that maintains a stable master branch and uses feature flags for seamless implementation. Key prerequisites for successful implementation include a modular codebase, skilled developers, a robust suite of unit tests, and an integrated feature flag system.
Branching Strategies: Feature Branches vs Branch by Abstraction
- 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