Feature flags technique improves the release management velocity without impacting the product management by turning on and off functionality during runtime.
Join the DZone community and get the full member experience. Velocity in agile development measures the quantity of work a team can accomplish in a sprint. It can be measured in story points, hours or days. The higher the velocity of a team, the more features it delivers, the more value it brings to customers. Sprint velocity is a good measure in sprint project management to evaluate and estimate team productivity. The measure of the velocity is based on multiple factors: the continuous integration (CI) process, the time to qualify the code changes, to test the regression, the security, the delivery, etc… In today’s world, product managers want features as soon as possible in production so the processes and the tools have to follow the velocity of the development. If the velocity of the development team is faster than the qualification of the changes, the result will probably be a delay in the deployment of the new features and potentially a decrease in the competitiveness of the company in a market that moves rapidly. Fortunately, to avoid that, multiple strategies exist today like the feature flag. They are an important part of a broader strategy to have an application that is adaptable to both technical and market needs. The feature flagging concept (also called feature toggling or feature switching) is widely credited to Martin Fowler, Jez Humble, and Facebook’s Engineering team. Within the context of continuous delivery, feature flags provided the foundation for a framework that would allow developers to release software faster with less risk and more control. From a coding point of view, feature flagging can be seen as simple as an „if“ statement which wraps around a new piece of code. When the „if“ statement evaluates to true, the feature flag is on, then the new code is applied. In a real software delivery example, the ‚if‘ statement described above would be evaluated differently depending on the environment in which the software is running. For example, if the application is running on a QA server, the feature flag will return true and the new functionality will be seen by the QA team to qualify the functionality. But, if the code is executed on a production server, the feature flag will return false and the functionality will be hidden. Feature flags play a key part in CI schemes where features are constantly being deployed but not necessarily „released“ into production. Since 2018, a lot of organizations use this concept in production. Their goal is to get the best from the product management team and the development team by improving the link between product management and release management. The idea is to defer the decision on questions related to the runtime as part of development strategy, DevOps strategy, and product strategy.
