Hi there, let's talk a little bit about feature flags. Feature flags are used to change how things work. Instead of making significant changes to the actual code within an app, you only need to make a small configuration change, and more often than not, this configuration change will only be necessary for a small number of users.

Leveraging feature flags provides an elegant solution when you would otherwise need to deploy new code into trunk, but not yet have it functional. Feature flags are typically implemented as the value of variables which are then used to control conditional logic.

The best way to explain feature flags is to use an example. So let's imagine a scenario where your team is working in the main trunk branch of an e-commerce application. Your manager has come to you and asked if it makes more sense to have the shipping cost calculations performed in the main branch instead of dealing with the messy operations of merge later on. How do you try this out without making wholesale changes to the app or, worse yet, breaking the app altogether?

In this case, you could use a feature flag to get around this. What you could do in this case is make a small change in your code so that users without the feature flag set continue using the original shipping calculation code while your team members who are working on the new shipping calculation code and who have the feature flag set see the new code that's being created.

This scenario would be an example of how to use a business feature flag which is used to determine business logic. The other type of feature flag is known as a release flag.

Now to demonstrate the use of a release flag, let's build upon our previous example. Let's assume your team has completed its work on the shipping calculation code. While you're pretty confident in your team's work you might be a little bit apprehensive about pushing this new code out to all of your users at once. In this case you'd rather push out the changes to a group of users that's better at dealing with new code and the issues that sometimes arise from that new code. This type of group consists of users that are referred to as canaries. The term canary comes from the old use of canaries in coal mines.

What you would do in this case is change the configuration so that your canary users also have the feature flag set. As a result they can start testing the new code as well while the original code continues to function for all other users. If things go south for the canary users you can quickly disable the flag for them so they can go back to using the original code.

So now that you've been introduced to feature flags in general, let's talk a little bit about their life cycle. The minute you use a feature flag for the first time, that feature flag gets added to the overall technical debt that you need to contend with. That in mind you need to realize that the longer a particular flag hangs around as part of your code, the bigger that technical debt becomes.

As you continue to add more and more feature flags to the code, that code becomes more and more complex. Ultimately you wind up with code that's more difficult to test than it needs to be and it's harder to maintain due to its complexity. This often makes it more difficult to troubleshoot because it becomes harder and harder to duplicate problems as part of that troubleshooting process.

To avoid these types of issues, you really need to remove unneeded feature flags as soon as you can. Developing a plan for managing your feature flag life cycle helps accomplish this. As soon as a flag is added to your code you need to have a plan for when it's going to be removed.

I should also point out that you should never repurpose feature flags. This is a big no-no because it opens you up to the possibility of using a flag for a new purpose even though that flag is still part of your code for its original purpose. This can cause all kinds of serious headaches.

To effectively manage the life cycle for your feature flags, start by making sure that you know which flags exist. You should also be keeping track of which feature flags are enabled in which environments. You should also, of course, have a plan for when your flags will be used in production and when they will be removed.

Implementing a feature flag management system such as this allows you to reap the benefits of those flags while keeping your technical debt to a minimum.

Lectures

Introduction - Identifying & Recommending Quality Metrics - Feature Flags - Technical Debt - Team Structures - Performance Testing - Inspecting & Validating Code Base for Compliance - Inspecting & Validating Infrastructure for Compliance - Secure Development & Coding - Infrastructure Security Validation Tools & Practices - Conclusion