Mege Hells! Feature toggles to the rescue
Have you ever wondered how Amazon does deployments in every 11 seconds? Have you ever wondered how frequently Google Chrome updates?
Compare that with an enterprise product you are using or the banking application that you use, it takes weeks or even months for an update. The assumption is that frequent releases are possible for Googles or Amazons or Unicorns. It is not for others.
This talk is about why that assumption is wrong. It can be done anywhere, with enough focus and investment for the Continuous Delivery pipeline to make sure that every commit is releasable or deployable.
And fundamental to Continuous Delivery is Continuous Integration. Continuous Integration guarantees every change committed to the repository is tested and reported about production readiness. And Feature Toggle is for turning features on/off depending upon certain conditions. This opens the opportunity to test certain features quickly with few users for experimentation and learning.
Feature branching has been popular for long, but everyone knows about the “code merge hell”, a common issue because of long-lived branches or infrequent integration. If the team is spending time in fixing the merge hells and checking what part of the code needs to be merged, then it is not the efficient use of human talent.
Outline/Structure of the Experience Report
- A small story about the typical last mile issue in Software Delivery
- Importance of Continuous Integration and its relation with Trunk based/Mainline development
- Feature toggles
- Types of Toggles
- Dark Side of Toggles
Feature Toggle is one of the key practices for Continuous Delivery, but not enough has spoken about the same. This session is to give an intro about Feature Toggle and explain the advantages it has over Feature branching and share my experience while using it for the last few years.
Feature toggles are supposed to be short lived, and if not, can contribute to Technical Debt. The session will touch upon the same too.