Feature toggles
The content here is under the Attribution 4.0 International (CC BY 4.0) license
Feature flags have become a standard practice for teams that want to deliver software fast into the hands of the users without disruption. with this approach, new challenges and ways of working come into play when writing code.
In a blog post by Peter published by Martin Fowler Feature Toggles aka Feature Flags an introduction, to the types of toggles and how to work with them. Let’s use the handbook by Pete and Patricio categorized as best practices to use with feature flags as a guide to share insights on the subject.
Why flags?
The first and foremost benefit of flags is the decoupling of deployment and release of a feature. For many software development teams, the release of a new functionality implies not only publicly opening it to their users, rather it is a stressful moment for the entire team, from the moment that the code is pushed until it gets into the users hand.
In this model, as I like to call it is: all in or nothing. If the feature that was released needs to be reverted, a new version needs to be deployed again. If it happens to be that a version contains an error or it causes an unplanned outage in production, the team needs to rollback what was deployed code-wise. If things are related with data it becomes even more complex. This scenario was described by Kent Beck as a “D-day”.
To support this scenario, git-flow emerged as a standard and it is a well-known way of delivering software. With git-flow, the cycle to release changes for users goes like this:
- branch off from the stable branch
- apply the changes
- spin up an environment that is just with this code.
- do the manual testing
- generate a tag with this release
- integrate the work backward in the development branch
- integrate the work in any branch that requires it
At first, it sounds like a good plan, but teams that work in that manner often reach an integration hell. More recently, practitioners started to scrutinize this approach and even degrade it in favor of a simpler flow. On the other end of the spectrum, there are simpler approaches to delivering software, but with that, there are some disciplines that need to proceed with the adoption of this technic.
Many teams of software ignore that technical practices matter so for example, it is important to have a continuous delivery pipeline with tests that developers trust and an environment that replicates what production looks like. The feedback loop is one of the most important things while developing software this becomes crucial for developers that are onboarding a new team and exploring unknown areas of the code base.
With the correct feedback loop and the trust ability of developers, it is the first step towards reducing the complexity and exploring trunk-based development. trunk-based development abstracts away the complexities of many versions of live sinking patches and the environmental complexities into that using a single wrench and keeping everyone on the same page at all times.
It sounds simple and actually, it is indeed, but the complexity now turns into the team and the technical practices that the team uses. One big shift is starting to use the feature. now, as a concept, things that someone can turn on or off to view new functionalities for specific users or specific environments or target a percentage of giving users in an application. Note that the complexity now lies in the code and not anymore in the version control system, one positive side effect of it is there is no need to keep merging and synching different branches with different code. The only worry is to make changes compatible with what already exists and avoid introducing breaking changes.
In the realm of trunk-based development and feature toggles, there’s a particular issue worth highlighting: code duplication. This concept, which often arises when practicing trunk-based development with feature toggles, is becoming increasingly important. I believe that maintaining a proper feedback loop and trusting in thorough testing will ensure code remains clean, effectively eliminating unnecessary code duplication. In the open-source community, certain projects utilize flags to control when specific features are enabled or disabled.
- ReactJs for example does that to experiment with new features, in their documentation there is a reference to their style of approaching it. How to Contribute to React - accessed 14 Apr, 2024
How does it work?
The first thing that developers start writing is a test targeting the functionality that is required. With flags this changes. The first test is to verify if the flag system is enabled.
Why should I care?
The different benefits and possibilities that are reported by blogs from professionals and companies are one of the key aspects that make the adoption of feature toggles an attractive option.
-
[Gitflow is a Poor Branching Model Hack by Vadim Samokhin Medium](https://medium.com/@wrong.about/gitflow-is-a-poor-branching-model-hack-d46567a156e7) - Please stop recommending Git Flow! – George Stocker
- Site Unreachable
-
[GitFlow considered harmful End of Line Blog](https://www.endoflineblog.com/gitflow-considered-harmful) -
[From Git Flow to CI/CD: A Practical Guide to Implement Git Workflow HackerNoon](https://hackernoon.com/from-git-flow-to-cicd-a-practical-guide-to-implement-git-workflow) -
[The Problem with Git Flow Hacker News](https://news.ycombinator.com/item?id=23622071) -
[Is Git Flow Overrated?. Git Flow is a very interesting thing… by Mario Serano Medium](https://medium.com/@marioserano55/is-git-flow-overrated-9e4b29a17b8b) - Git Branching Strategies: GitFlow, GitHub Flow, Trunk Based…
Tools
- configcat
- growthbook
- posthog