Why we used Feature Branching


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • JIRA OSGI based5 Different Databases supported, multiple versions of each database
  • 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
  • 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…
  • 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….
  • No rollback or quick upgradeCustomer could accidently get into a “Disabled” UI for an untested feature.Memory LeakThis also represents a security risk
  • Manual QA stage can become a bottleneck and commits get batched together at this stage
  • I wouldn’t wish Subversion merging branches on my worst emery
  • Each Pull Request has a build, this includes the result of being merged to Master – You do you risk a race condition
  • 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
  • Why we used Feature Branching

    1. 1. Why we used Feature Branching Alan Parkinson CEO, Hindsight Software Ltd
    2. 2. we publish a Universal Binary that supports 7 platform versions with breaking API changes
    3. 3. Deploy to Production Functional Tests Commit Stage Deploy to UAT Deploy to Dogfood Every 3 weeks Early Access Customers: Hourly or Daily release
    4. 4. A Feature Toggle Headache Customers deploy to their own hardware = Little control over data and feature toggles
    5. 5. 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
    6. 6. Technical Support Increased complexity and incidence rates
    7. 7. 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
    8. 8. Noisy Testing Batching many unrelated commits together is a headache for risk based test analysis
    10. 10. 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
    11. 11. 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
    12. 12. Merging is HARD work Refactoring code is bad for merging Use a SCM with good merge support – git Do small merges
    13. 13. Merging is a CHANGE to the codebase Tests are run Before and After the merge
    14. 14. Feature Branches in CI? Once upon a time you couldn’t get CI for feature branches. It’s now possible with Jenkins and Bamboo
    15. 15. Branches can diverge massively Every feature branch build merges from master before compiling
    16. 16. 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
    17. 17. Questions? Alan Parkinson - @alan_parkinson CEO, Hindsight Software