How I push unfinished work to production (and why you might too)

Question:

How do you implement a large feature?

If you are like 90% of developers, you:

• Create a new branch.
• Push the code for weeks to it.
• Have a large test and release at the end of the development cycle.

If that’s you, don’t worry.

I was doing the same thing several years ago.

But there are 3 major problems with that approach:

1. Other developers push code to the main branch - since I was working on a project where other developers have been actively pushing code to the main branch, I had to merge that code into my branch. And often had to solve merge conflicts.
2. Testing a big chunk of code is time-consuming - Once I implemented the feature, the QA team got a big set of user stories they had to test. The testing took a while, and often there was not enough time to thoroughly test all edge cases.
3. The release brings bugs that the feature has introduced - The release of a big feature to production was a major event for the whole team. And customers found some issues with the new feature that we haven’t considered testing.

Instead of fixing all three problems separately, you can fix them all at once.

How?

By pushing code to production faster.

Even the code for unfinished features.

The solution is feature flags.

Let me show you how.

What are feature flags?

In their simplest form, feature flags are boolean conditions you put in various places in code to control execution between two different code paths.

That means you can control whether or not a work-in-progress feature is visible in production.

Imagine this scenario:

You need to upgrade the order process for a webshop site.

Currently, the site uses a simple order checkout with a random payment provider.

But the new requirements are:

• Use PayPal and Stripe as payment providers
• Offer different discount options
• Offer different ways of delivery

How can feature flags help you?

Well, where you have the logic to trigger the order flow, you add a check on whether to use the new or old implementation.

// Feature flag to control whether a new feature is enabled or not
bool useNewOrderProcessingFlow = true;

if (useNewOrderProcessingFlow)
{
    Console.WriteLine("New Ordering flow is enabled! Performing new feature actions…");
    NewOrderProcessingFlow();
}
else
{
    Console.WriteLine("New Ordering flow is disabled. Performing default actions…");
    OldOrderProcessingFlow();
}

You can store feature flags states in:

• Database
• Configuration file
• External system

But more on implementation details soon.

Let’s go back to implementing the new order feature.

To implement a big feature such as ordering mentioned above:

1. You create a feature flag and set it to false.
2. You continuously release the code for a new feature.
3. The code changes are not yet visible to the end customer.
4. Once you finish the feature and it’s ready to be released, you turn the feature flag to true.
5. Now the customers see the new feature.
6. After a while, you remove the feature flag.

If there is a critical bug with the new feature, you can easily turn off the feature flag until you fix the issue.

If your next question is: “Wait, doesn’t this lead to a bunch of if-else statements throughout the code?”

The short answer is yes. That’s how most teams implement feature flags.

But there is another way. The one that doesn’t include if-else all over the place.

I’ll talk about it soon.

What tools can you use to implement feature flags?

To implement feature flags in your application, you have the following options:

1. Do it yourself - create an infrastructure for handling feature flags. Store feature flag states into a configuration file or a database.
2. Use .NET Feature Management libraries - these are ASP.NET Core libraries from Microsoft you can use to implement feature flagging.
3. Use a paid 3rd party tool - Plenty of tools available. The most popular is LaunchDarkly, but there are plenty more.
4. Use a free 3rd party tool - Some examples are PostHog, Unleash, and Flagsmith.

Here is a code snippet when you use ASP.NET Feature Management:

IFeatureManager featureManager;
...
if (await featureManager.IsEnabledAsync(MyFeatureFlags.FeatureA))
{
    // Run the code behind the feature flag
}

What about database changes? How can you hide that behind a feature flag?

Two main approaches that you can take are:

• Easy - deploy DB changes as soon as they are ready.
• Complicated - deploy only what you can. Often, that’s just the new stuff, tables, views, etc. For breaking changes, it’s possible to use a stored procedure that will be automatically executed when a feature flag is turned ON.

How do you avoid having a codebase littered with zombie feature flags? What’s the expiry mechanism/criteria?

Unfortunately, there is no silver bullet regarding retiring feature flags.

I usually create a separate task to remove the feature flag and include that task in a sprint one month after the feature has been enabled globally to all customers.

You must remove feature flags aggressively.

Or even agree with the team on a maximum number of allowed feature flags simultaneously.

Otherwise, you can end up in a situation where the same code has 2 or even more feature flags that you can configure at once.

This soon leads to a scenario where you only have a bug when feature 1 is on, and feature 2 is off.

Avoid that.

When it comes to tools available, the one that I found was piranha from Uber. It’s available for Javascript, Java, Swift, and Objective-C.

Unfortunately, I couldn’t find a tool for .NET.

But you can make a script or a tool to automate some parts of feature flag removal.

How do you avoid having if/else statements related to feature flags all over the codebase?

If you have changes implemented behind a feature flag all over the codebase, the if-else statement can impact code maintainability.

To prevent this, you can use branching by abstraction.

This means that instead of if-else statements you:

1. Identify the code that needs to be changed.
2. Put into a separate class.
3. Introduce an interface for it.
4. Provide an alternative implementation of the interface that contains new changes.
5. Use dependency injection to inject different implementations based on the feature flag status.

This is an excellent alternative to using if-else statements. Read more about it here.

Does this only work for simple apps?

So far, I have successfully used feature flags in 3 big enterprise projects.

2 big monoliths where the code was 6+ and 10+ years old.

The 3rd one was the microservices application.

Therefore, the actual size and age of the codebase are not limiting factors.

Once you start using feature flags, your development flow will become easier with less pressure during testing and release.