Feature flag & toggle
TL;DR -> Don’t have time 🙂? Check out this repository where I present an easy way to include feature toggle in your API. Enjoy!
Introduction
In many companies, during long migrations from monolith-based software to microservices, the idea of continuous deployments feels something out of reach.
- Current deployments are done partially with manual steps.
- Security is a big thing and teams can’t afford to mess things up.
- Managers want to know what, why, and how a deployment occurs.
- Many legacy companies have deployment times of several days, giving them a sense of control of what their clients receive in production. The idea of reducing the time from committing to deploying to production to minutes scares them.
There are many other reasons why the adoption of continuous deployments seems impossible. In the next sections, I’ll (try to) show you a simple way your team(s) can embrace continuous deployments with the help of feature toggles.
The simple case: A web API
Let’s say you, as a developer, are creating a web API and you want to deploy it. Let’s assume your API has a dependency with a legacy part of your platform that needs to be deployed manually. You are decided to embrace continuous deployments so you decide to apply feature toggle for your API.
The idea is simple:
- Develop and test your endpoint as usual.
- Deploy it deactivated.
- Once your dependency is also there, activate it with feature toggles.
Step 1: Development
You are developing an endpoint that calls another legacy service. Something similar to this:
<Add image here>
As you can see, the endpoint calls the dependency and performs some extra steps. Also, we added an attribute (on top of the endpoint) and a middleware (in the Startup.cs file) that will perform the feature toggle for us.
The attribute defines the endpoint as the feature, in our case feature-name.
In addition, the middleware takes care of:
- Retrieving the name of the feature based on the attribute.
- Call an external service to know if the feature is activated or not.
In this example, we did not include the external service since this is something that would depend on your specific use case. This external service could be fast-access storage such as DynamoDB, Redis, CloudMap, …
Step 2: Deployment
Let’s test the solution by launching it locally and calling the endpoint. For the sake of this example, the service will always return a response telling us if the feature is activated or not.
The first test brings
Step 3: Activation
