No content

No content

Ian Jenkins [email protected] 

Feature Flag Toggle Flipper Switch Condition 

A feature flag is a technique in software development that attempts to provide an alternative to maintaining multiple branches in source code (known as feature branches), such that a software feature can be tested even before it is completed and ready for release. Feature toggle is used to hide, enable or disable the feature during runtime. https://en.wikipedia.org/wiki/Feature_toggle Feature flags give a software organization the power to reduce risk, iterate quicker, and gain more control. Feature flags allow you to decouple feature rollout from code deployment. https://featureflags.io/feature-flag-introduction/ Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. https://martinfowler.com/articles/feature-toggles.html 

Feature Flags are a software development technique that allows us to control the release of features independent of code deployment. This allows us to iterate quicker; testing features before they are complete to reduce risk and increase flow. https://www.boxuk.com/insight/coding-with-feature-flags/ 

No content

No content

Types of Flags 

● Experiment Flags ● Ops Flags ● Permissioning Flags ● Release Flags https://martinfowler.com/articles/feature-toggles.html 

Experiment Flags ● Enable feature(s) for a limited number of users ● Measure the feature on vs the feature being off ● A/B testing 

Ops Flags ● Gracefully degrade some functionality when under load ● Idea of a ‘kill switch’ for certain features 

Permissioning Flags ● Turn on for a certain set of users ● Could be premium features for premium members ● Or, early access for those signed up to the beta program 

No content

Release Flags ● Allow in-progress features to be checked into source control without affecting deployment ● Decouples the deployment from a release ● Enables Continuous Delivery 

Continuous Delivery 

Continuous Delivery is all about deploying little and often. This historically was a problem because you could have multiple developers working on multiple streams of work and you would find that one team might be ready to release one stream, but not the other. 

● Wait for all development streams to be complete. This leads to a heavy, bloated deployment potentially containing lots of code changes and interdependencies. Often this is prone to bugs that often don’t show up until production, and a long and arduous deployment process. ● Work in separate release branches, so that each stream of work can be deployed independently. The problem here is it quickly becomes messy. You have diverged work, hot fixes you need to apply into multiple branches and a high risk of conflicts. 

No content

The 3 ways 1. The Principle of Flow The First Way requires the fast and smooth flow of work from Development to Operations, to deliver value to customers quickly. 2. The Principle of Feedback The Second Way describes the principles that enable the reciprocal fast and constant feedback from right to left at all stages of the value stream. Our goal is to create an ever safer and more resilient system of work. 3. The Principle of Continual Learning and Experimentation The Third Way focuses on creating a culture of continual learning and experimentation. These are the principles that enable constant creation of individual knowledge, which is then turned into team and organizational knowledge. 

The Principle of Flow 

Lead Time is the time between the appearance of a task on your project board and its progression to being marked as ‘Done’. 

Cycle Time is the time that a task is in progress before being marked as ‘Done’. 

In order to increase flow you need to reduce both lead and cycle time and get code into production as often and smoothly as possible. 

Any work not on production is effectively in a queue and requires handover 

Bigger Queues == Bigger Deployments == Bigger Risk == Lower Confidence 

No content

No content

No content

Using Feature Flags in PHP 

Symfony? 

DZunke FeatureFlagsBundle https://github.com/DZunke/FeatureFlagsBundle 

Flagception https://github.com/bestit/flagception-bundle 

Laravel? 

Feature Flags for Laravel https://github.com/ylsideas/feature-flags 

WordPress? 

Flagpole https://github.com/jamesrwilliams/flagpole 

Flagpole ops flag ops flag ops flag ops flag release flag release flag release flag release flag experiment flag experiment flag Permissioning Flags - very basic for now, can ‘preview’ for your user 

None of the above? 

LaunchDarkly https://launchdarkly.com/ 

LET’S DO A RELEASE ON A LIVE SITE 

Wrapping Up 

● Feature Flags aren’t too difficult to implement, can start off basic ● There are multiple types of flags ● Release flags allow us to make use of Continuous Delivery ● Continuous Delivery helps reduce risk, gain confidence, deploy more often ● Plenty of good libraries out there to get going ● Releasing during a talk is a great/terrible idea (adjust depending on how it went) 

No content

Ian Jenkins [email protected] Thanks! https://www.boxuk.com/insight/coding-with-feature-flags/