What the Hell are Feature Flags?

In recent years, Feature Flags have become an indispensable part of a lot of companies, but what are they?

Feature Flags go by many names — Feature Toggles, Feature Switches, etc. But regardless of the name, they all refer to the same development technique.

This development technique essentially allows you to turn features on and off at the run time, without changing the code, just by turning on and off a switch on a third-party provider (you can of course implement your own Feature Flag Service)

High level concept view of Feature Flags

Let’s take a closer look.

First, we would need to define our new Feature Flag in our third-party provider.

This would differ from one service to the other, but imagine something like this.

Next, we would need to make a request in our code that checks whether or not our Feature Flag is on or off.

const isNewFeatureEnabled = await getFeatureFlagFromThirdParty(newFeature)

And then we would take one path or another based on the result of said request.

if(isNewFeatureEnabled){
  newFunction()
} else {
  oldFunction()
 }

This provides a lot of advantages. Just by turning on and off a switch, we can execute one code or another.

Imagine you are now pushing new code to production, maybe a new Feature, with Feature Flags you can now feel much safer, should your new code cause the dreaded regression with just the turn of a switch you can go back to the way it was before.No need to rollback through complicated re-deploys.

And that’s just the tip of the iceberg, Feature Flag services come with many additional functionalities like being able to activate a code to a certain number of clients ( maybe you want to introduce the new Feature for just 10% of your user base), maybe you want to do A/B testing, etc.

#javascript #devops #programming #feature-flags #nodejs

What is GEEK

Buddha Community

Getting Started With Feature Flags

Introduction

As any developer can tell you, deploying any code carries technical risk. Software might crash or bugs might emerge. Deploying features carries additional user-related risk. Users might hate the new features or run into account management issues. With traditional deployments, all of this risk is absorbed at once.

Feature flags give developers the ability to separate these risks, dealing with one at a time. They can put the new code into production, see how that goes, and then turn on the features later once it’s clear the code is working as expected.

---

What is a Feature Flag?

Simply put, a feature flag is a way to change a piece of software’s functionality without changing and re-deploying its code. Feature flags involve creating a powerful “if statement” surrounding some chunk of functionality in software (pockets of source code).

---

The History of Feature Flags

Leading Web 2.0 companies with platforms and services that must maintain performance among high traffic levels led the way in regard to developing and popularizing new deployment techniques. Facebook, in particular, is known as a pioneer of feature flags and for releasing massive amounts of code at scale. While building its massive social network more than a decade ago, the company realized that its uptime and scale requirements could not be met with traditional site maintenance approaches. (A message saying the site was down while they deployed version 3.0 was not going to cut it).

Instead, Facebook just quietly rolled out a never-ending stream of updates without fanfare. Day to day, the site changed in subtle ways, adding and refining functionality. At the time, this was a mean feat of engineering. Other tech titans such as Uber and Netflix developed similar deployment capabilities as well.

The feature flag was philosophically fundamental to this development and set the standard for modern deployment maturity used by leading organizations everywhere today. Recently, feature flags have been used in tandem with continuous delivery (CD) tools to help forward-looking organizations bring features, rather than releases, to market more quickly.

#devops #continuous integration #ci/cd #continous delivery #feature flags #flags #feature branching #feature delivery

What the Hell are Feature Flags?

In recent years, Feature Flags have become an indispensable part of a lot of companies, but what are they?

Feature Flags go by many names — Feature Toggles, Feature Switches, etc. But regardless of the name, they all refer to the same development technique.

This development technique essentially allows you to turn features on and off at the run time, without changing the code, just by turning on and off a switch on a third-party provider (you can of course implement your own Feature Flag Service)

High level concept view of Feature Flags

Let’s take a closer look.

First, we would need to define our new Feature Flag in our third-party provider.

This would differ from one service to the other, but imagine something like this.

Next, we would need to make a request in our code that checks whether or not our Feature Flag is on or off.

const isNewFeatureEnabled = await getFeatureFlagFromThirdParty(newFeature)

And then we would take one path or another based on the result of said request.

if(isNewFeatureEnabled){
  newFunction()
} else {
  oldFunction()
 }

This provides a lot of advantages. Just by turning on and off a switch, we can execute one code or another.

Imagine you are now pushing new code to production, maybe a new Feature, with Feature Flags you can now feel much safer, should your new code cause the dreaded regression with just the turn of a switch you can go back to the way it was before.No need to rollback through complicated re-deploys.

And that’s just the tip of the iceberg, Feature Flag services come with many additional functionalities like being able to activate a code to a certain number of clients ( maybe you want to introduce the new Feature for just 10% of your user base), maybe you want to do A/B testing, etc.

#javascript #devops #programming #feature-flags #nodejs

Feature Flags for True Continuous Deployment

Even the best software development teams I work with struggle to solve the problem of _completely automated deployment_s to their production environments. The biggest hurdles to this tend to take the form of:

• Production change management that requires manual approval
• Even microservices architectures that have dependencies on multiple services being bundled and deployed together
• Unable to separate the idea of a version and deployment

There are several strategies we can apply to solve those points individually, but one simple trick to solving all these issues with one pattern is to apply Feature Flags to your code.

---

Ultimate Shift-Left Development Practices

Source

It does not matter if you are developing on an older monolithic application or a greenfield microservices architecture application; you can introduce feature flagging into either pattern. In addition, with the industry standard of agile development, it can be near impossible to code an entire net new feature in a single sprint. Using feature flags, we can simply default our new code to “off" and regardless of who asks for what during our sprint, we can package our app and deploy it without worrying about something breaking.

---

Test in Production!

Yes, you’ve read that right. I am advocating you use feature flags to test in prod! Alright, well, hold on — before you start getting crazy thoughts and think I’ve lost my mind, let me clarify.

There are a few areas where we can use feature flags and turn things on in production without causing a major impact to our end-users:

• Background load testing: Let’s say we have a new feature that we know is going to be pretty chatty. Maybe it’s the ability to send real-time messages to other users or real-time collaboration on a document. Instead of trying to simulate user load and action in a QA/performance environment before flipping the switch in production and releasing our shiny new feature, we can actually use real users to simulate the traffic load. This is actually a famous tactic Facebook used before rolling out messaging to its user base. For months, bits of JavaScript were sending messages to your other friends, and unless you had a packet sniffer open, you’d never know!

#software-development #feature-flags #javascript #startup #programming

Tinder Features: A complete and in-detail list

There are a wide number of dating apps around the world, but only Tinder became successful. Do you know the reason for its success? The primary reason why tinder is able to attract users around the globe is because of its simple yet attractive features.

Due to distinct features along with the highly-interactive UI UX, millions of users are getting attracted to this dating app.

Do you want to know the features present in the most popular dating app in the world, then we have got you covered. Here, we have made an exclusive list of all the Tinder Features.

#Tinder Features #Tinder gold features #Tinder App Features

Use Spring Security and Feature Flags to Test in Production

Okta is used as an Access Management and Identity platform. In short, Okta shoulders the responsibility of secure authentication and authorization, allowing you to spend time on other necessary tasks, such as the business logic of your app.

Not unlike peanut butter and chocolate, Okta and Spring Boot already go together well, and adding in feature flags care of Split allows you to test your app without having to redeploy. Talk about testing production in a smart way! In addition to all of this, you are also able to leverage Okta’s groups to easily manage who should see new content and who sees old content.

In this tutorial, I will be going through the steps to show you how to test in production. I will walk you through how to set up an Okta org, and configure an OpenID Connect App. I will also cover how to integrate Okta into a simple Spring Boot and Spring security app. Lastly, I will show you how to add feature flags to deliver a new UI experience for select users; who you can organize by group.

#spring boot #spring security #feature flags #access management