Feature Branching considered Evil
Feature branching is again gaining in popularity due to the rise of Distributed Version Control Systems (DVCS) like Git and Mercurial. With DVCSs, branch creation became very easy. But it comes with a certain cost. Long living branches break the flow of the software delivery process impacting throughput and stability.
This session explores some of the reasons why teams are using feature branches, what problems are introduced by using feature branches and what techniques exist to avoid them all together. In conclusion it explores what is exactly evil about feature branching. Which is not necessarily the problems they introduce. But rather the real reasons teams are using them for.
The key takeaway is an appreciation of a different branching strategy and how it relates to Continuous Integration.
Outline/Structure of the Talk
As a 45 min session, it would likely run like this:
0:00 Introduction: A tale of 2 teams: one using trunk-based development, the other using GitFlow. And how I came to speak about this topic.
0:05 Clarifying some definitions: Continuous Integration, Feature Branch, Mainline and What is the goal of Software Engineering?
0:08 Why are teams using Feature Branches ? Some reasons I got when discussing the topic with proponents of feature branching.
0:12 What are the problems introduced by Feature Branching ? An overview of the problems I encountered when using feature branches in teams.
0:22 How can we avoid the use of Feature Branching ? An introduction to Trunk Based Development. How to achieve Trunk Based Development through the use of incremental development, decoupled code bases, hiding functionality, branch by abstraction and feature toggles.
0:32 Some practical questions I regularly get asked by teams when I suggest Trunk Based Development. What should be the size of a User Story ? How to perform Code Reviews ?
0:36 What are the benefits of Trunk Based Development ?
0:38 Conclusion: What is evil about Feature Branching ? Explaining that Feature Branching is more like a symptom treatment, and the evilness lies behind it meaning: what are the real reasons teams are using them for ?
0:40 Questions
Learning Outcome
After the session, attendees will be able to:
- explain why feature branching is problematic.
- describe alternatives to feature branching.
- assess when feature branching is acceptable.
- run an experiment with trunk based development.
Target Audience
Anyone using version control systems in a Continuous Integration and Continuous Delivery context.
Prerequisites for Attendees
Attendees should have a practical experience with version control systems and continuous integration.
Video
Links
Unfortunately I don't have a blog-post (yet) on the topic, only previous presentations.
SoCraTes FR 2016 - Feature Branching is Evil : first draft at an open space conference where I shared my ideas and started the conversation on the subject.
Continuous Delivery Conference NL 2016 - Feature Branching is Evil : first final version based on the conversations at SoCraTes FR and on Twitter. Talk duration: 40 min.
XP2017 - Feature Branching is Evil : second iteration; more details on the reasons for using feature branches; the addition of one extra problem introduced by feature branching; a clarification that feature toggles are not easy and can be evil too; the addition of a “Benefits of Trunk Based Development” section; the removal of the “Can all teams adopt Trunk Based Development ?” section because it was redundant with the conclusion.Talk duration: 60 min.
XPDays Ukraine 2017 - Feature Branching is Evil : third iteration, added some verbal clarification about the difference between GitFlow feature branches and GitHub Flow feature branches; some more visualisations. Talk duration: 45 min.
More of my presentations can be found on Speaker Deck.
schedule Submitted 5 years ago
Call for Proposals CLOSED
Ended on Nov 22 '17 11:00 AM IST
All proposals will be public. Registered user of the submission system will be able to comment on your proposal. You are required to reply to those comments to provide clarifications, explain revisions and respond to questions. The program team will look at how well you've responded to comments and updated your proposal to incorporate public suggestions. Ultimately the decision to accept a session resides with the program team.
Your proposal stands the best chance to be selected, if it's unique, fully flushed, ready-to-go. Please ensure you've read:
To encourage early submissions and iterative improvement of proposals, we'll start accepting proposals as soon as we find them a good fit. As time passes by, the competition gets tougher. So don't wait till the last date to submit your proposal.
Leena S N
Ravi Kumar
Archana Joshi
Prasad
Naresh Jain
