Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Feature Branching vs. Feature Toggling

No description

Thomas Malt

on 13 August 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Feature Branching vs. Feature Toggling

Let's us merge unfinished functionality to
One of the most common arguments in favor of FeatureBranch is that it provides a mechanism for pending features that take longer than a single release cycle.
When finished, code is merged back into the common source tree.
Feature Branching

Feature Toggling

Bitter Enemies or Beautiful Friends
Feature Branching
is when you're creating a separate branch in source code for each feature to be implemented.
The pattern we use is called
A branch needs to be short lived. Just the time needed to implement it. After code review it is merged back into the common tree. Our general rule is 3-5 days maximum.
Of course you need Continuous Integration for each branch.
For bigger long-lived branches you need a complete CI-integration toolchain for each branch.
Never skip testing.
Automated testing for all long lived branches is a must.
Feature Toggling
Martin Fowler says:
We run into this issue quite a lot and feature toggles are a handy tool to deal with it.
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?
I say:
This reads more like a description of the importance of doing Feature Branching right, not a dismissal of it.
Feature Branching
makes it easier to maintain control as team grows larger.
Feature Branching
help the team scale better. It's easier to maintain pace as team and complexity grows.
Feature Branching
helps us improve our process for doing Code Review and proper QA for each task.
Implement a system to turn the availability of a feature on or off as needed
This adds a an extra layer of bug prone complexity to your application.
The feature toggle system needs to be maintained and kept up to date just as every other critical part of your system.
A small oversight might make everything blow up in production.
Feature toggling is functionality every modern system should have.

Even if we're able to do agile feature branching, having a feature toggle system in place lets us have it both ways.

Lets try to do both fast feature branching and feature toggle to have full control over what users see.
Let's us control when we release functionality to ordinary users.
This makes it easier to implement
A/B testing
focus groups
and deployment to
first for example.
Feature Branching
Continuous Integration
Promiscuous Integration
Logic has to be added to all parts of the code to check if the feature should be enabled or not.
A clear architecture and proper Configuration Management needs to be in place to deal with it.
I say:
Our Situation
The Definition of Done
Continuous Improvement
Remote Pair Programming
Our Approach
x 7
Understanding Quality
Shared Ownership
Cross Functional teams
develop master production
without breaking systems.
Full transcript