SlideShare a Scribd company logo

Why we used Feature Branching

•Download as PPTX, PDF•
•
Alan Parkinson
Alan Parkinson

The document discusses why the author's company switched to using feature branching for their development workflow. Key reasons included reducing risks from untested code in production due to improperly configured feature toggles, which led to increased technical support costs. Feature branching provides a safer approach by having each new feature or change developed on a dedicated branch, with pull requests and testing occurring before code is merged to master. This allows for incremental changes to be made and tested independently, reducing risks compared to batching many changes together without proper testing.

1 of 19
Why we used Feature Branching Alan Parkinson CEO, Hindsight Software Ltd
Why we used Feature Branching
Why we used Feature Branching
we publish a Universal Binary that supports 7 platform versions with breaking API changes
Deploy to Production Functional Tests Commit Stage Deploy to UAT Deploy to Dogfood Every 3 weeks Early Access Customers: Hourly or Daily release
A Feature Toggle Headache Customers deploy to their own hardware = Little control over data and feature toggles
Knight Capital lost $440 million in 30 minutes “the problem might be a test program in production—or, possibly, a configuration flag that wasn't ready for production and should have been turned off” Rick Lane, CTO of Trading Technologies
Technical Support Increased complexity and incidence rates
Disabled by Obscurity “one danger with feature toggles is an accidental exposure, when someone forgets to wrap the UI feature in a toggle tag” Martin Fowler
Noisy Testing Batching many unrelated commits together is a headache for risk based test analysis
FEATURE BRANCHING OUR WAY
Inexperienced Team Junior team members are reassured by the safety net No “jack of all trades”, people collaborate on branches Pull Requests offer a learning opportunity
Our take on Feature Branching • Build from master for releases • No direct commits to master • Each issue/feature/bugfix has a branch • No merges to master, open Pull Requests • Manual testing occurs on Pull Requests
Merging is HARD work Refactoring code is bad for merging Use a SCM with good merge support – git Do small merges
Merging is a CHANGE to the codebase Tests are run Before and After the merge
Feature Branches in CI? Once upon a time you couldn’t get CI for feature branches. It’s now possible with Jenkins and Bamboo
Branches can diverge massively Every feature branch build merges from master before compiling
Summary Loosing control of Feature Toggle configuration management significantly increased our Technical Support costs We went back to the drawing board and mitigated known issues with Feature Branching
Questions? Alan Parkinson - @alan_parkinson CEO, Hindsight Software

More Related Content

Why we used Feature Branching

  • 1. Why we used Feature Branching Alan Parkinson CEO, Hindsight Software Ltd
  • 4. we publish a Universal Binary that supports 7 platform versions with breaking API changes
  • 5. Deploy to Production Functional Tests Commit Stage Deploy to UAT Deploy to Dogfood Every 3 weeks Early Access Customers: Hourly or Daily release
  • 6. A Feature Toggle Headache Customers deploy to their own hardware = Little control over data and feature toggles
  • 7. Knight Capital lost $440 million in 30 minutes “the problem might be a test program in production—or, possibly, a configuration flag that wasn't ready for production and should have been turned off” Rick Lane, CTO of Trading Technologies
  • 9. Disabled by Obscurity “one danger with feature toggles is an accidental exposure, when someone forgets to wrap the UI feature in a toggle tag” Martin Fowler
  • 10. Noisy Testing Batching many unrelated commits together is a headache for risk based test analysis
  • 12. Inexperienced Team Junior team members are reassured by the safety net No “jack of all trades”, people collaborate on branches Pull Requests offer a learning opportunity
  • 13. Our take on Feature Branching • Build from master for releases • No direct commits to master • Each issue/feature/bugfix has a branch • No merges to master, open Pull Requests • Manual testing occurs on Pull Requests
  • 14. Merging is HARD work Refactoring code is bad for merging Use a SCM with good merge support – git Do small merges
  • 15. Merging is a CHANGE to the codebase Tests are run Before and After the merge
  • 16. Feature Branches in CI? Once upon a time you couldn’t get CI for feature branches. It’s now possible with Jenkins and Bamboo
  • 17. Branches can diverge massively Every feature branch build merges from master before compiling
  • 18. Summary Loosing control of Feature Toggle configuration management significantly increased our Technical Support costs We went back to the drawing board and mitigated known issues with Feature Branching
  • 19. Questions? Alan Parkinson - @alan_parkinson CEO, Hindsight Software

Editor's Notes

  1. Start-upFollow Learn Start-upBuilt a MVP on top of JIRA – Consequence is customers install on there own hardwareWe pratitice CD during product development and always looking to get feature into customers handsMobile app developers may face similar issues to us as there are many parallels
  2. JIRA OSGI based5 Different Databases supported, multiple versions of each database
  3. Publishing aims -* 3 Weeks for Marketplace* Hourly or daily for EAP Customers For shrink wrapped software I think we did a pretty good job with these timelines, we can take
  4. We can’t force rollbacks or upgradesCustomers might not restore or backup feature toggle related data.Good Configuration management is a must for Feature Toogles…Examples…
  5. Loosing control of the Feature toggle configuration management had a penalty in area not often associated with CD, Technical SupportCompared to our feature branch implementation….Increased data collection for each support incidence x3 times bigger. History of feature toggle changesWhy can’t we see this feature….
  6. No rollback or quick upgradeCustomer could accidently get into a “Disabled” UI for an untested feature.Memory LeakThis also represents a security risk
  7. Manual QA stage can become a bottleneck and commits get batched together at this stage
  8. I wouldn’t wish Subversion merging branches on my worst emery
  9. Each Pull Request has a build, this includes the result of being merged to Master – You do you risk a race condition
  10. This keeps your branch only one commit away from being able to be merged backBranches shouldn’t live more than a few days or 2 weeks