Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Feature Branching vs. Feature Toggling
Transcript of Feature Branching vs. Feature Toggling
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.
Bitter Enemies or Beautiful Friends
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.
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?
This reads more like a description of the importance of doing Feature Branching right, not a dismissal of it.
makes it easier to maintain control as team grows larger.
help the team scale better. It's easier to maintain pace as team and complexity grows.
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
and deployment to
first for example.
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.
The Definition of Done
Remote Pair Programming
Cross Functional teams
develop master production
without breaking systems.