{"id":27804,"date":"2019-09-26T12:59:53","date_gmt":"2019-09-26T16:59:53","guid":{"rendered":"https:\/\/centricconsulting.com\/?p=27804"},"modified":"2021-12-15T00:16:40","modified_gmt":"2021-12-15T05:16:40","slug":"using-feature-toggles-to-increase-product-owner-release-control","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/using-feature-toggles-to-increase-product-owner-release-control\/","title":{"rendered":"Using Feature Toggles to Increase Product Owner Release Control"},"content":{"rendered":"
Whenever joining a new development team, there is an inevitable debate on \u201cbranching\u201d strategy. The branching strategy debate centers around how to manage multiple feature development streams while still maintaining the ability to release small enhancements and bug fixes continuously.<\/p>\n
This debate elicits a lot of passion around the most effective way to achieve agility, stability, and release management control. As agile<\/a> becomes a de-facto standard, and as continuous delivery and feedback is an increasingly important business and IT imperative for success, our team migrated away from a \u201cBranching Strategy\u201d to a Feature Toggle pattern.<\/strong><\/p>\n This article details the fundamental principles and example usage of Feature Toggles.<\/p>\n In its simplest form, a Feature Toggle is a simple lever that allows the team to enable or disable a production feature without having to redeploy software. Whether a team works on a core transactional system replacement or enhances an existing application, there will be a mismatch between the completeness of different features.<\/p>\n Many agile teams revert to complex strategies to manage the rollout imbalance. One option teams use is complex release planning schedules where the team holds releases until they complete a certain set of features. This process leads to a long lead time for simple changes since these require a delay until the more complex features reach maturity.<\/strong><\/p>\n Another option is creating multiple feature branches where you keep longer-running features out of the mainline deployments. This process allows the teams to deploy the small changes quickly since large changes are separated from mainline. However, this option introduces a problem of stale feature branches. Multiple feature branches can pull from mainline, but they don\u2019t \u201csee\u201d the major changes occurring across the other feature branches. This step limits the amount of refactoring done in each branch and increases the complexity of merges when the feature branches complete.<\/p>\n To address these issues, our agile team introduced Feature Toggles across the system. The Feature Toggles allow us to control the availability of features in production which we accomplished with a few minor upgrades to our existing permissions system.<\/p>\n We can use the Feature Toggles at both a macro level, where we enabled full menu items and business processes<\/a> for a select set of users and small features, such as a single additional button.<\/p>\n Finally, allowing A\/B testing of replacements for existing features is another usage pattern.<\/p>\n Below is an example of a simple feature toggle where we added a new button to an existing UI view. The screenshot is from the same car-rental company system example I used in my previous Behavior Driven Development (BDD)<\/a> blog. The first image is the view for most of the users.<\/p>\nWhat Are Feature Toggles?<\/h2>\n
Feature Toggles in Practice<\/h2>\n