DEV Community

Łukasz Reszke
Łukasz Reszke

Posted on • Originally published at

Disabling unready code with Azure Feature Management

Working without branches and PRs

When my team and I started developing new product, I was looking for a way to deliver high quality code effectively. Previously most of us worked with branch-based workflows with Pull Requests. From my experience it's quite standard way. I haven't seen many projects or meet many people working differently. However, I did work once in an green field'ish project with PRs. It was quite annoying. Especially, when for the POC phase I was alone. I was taught to do it like that and I didn't think about more effective ways.

Looking for inspiration

But in the meantime when we were starting that project I joined polish dev Instagram community and had a chance to talk with @andrzejkrzywda . Andrzej is CEO of Arkency, consulting agency that works with Ruby and Rails. The thing that makes Arkency special (and that was mind-blowing for me) is the fact that they have their own, very specific workflow. And yet, very different than what is accepted. Andrzej did some marketing on the Instagram stories. And it couldn't end up different. I bought the Async Remote book, where I learned of how developers in Arkency work... without branches (there are also few other interesting things in their workflow, check the book out).

Chance to test things out

I thought to myself that a Greenfield-ish project, that we need to develop sooner than later, is a good opportunity to at least try no-branches approach from the beginning. At the end of the day it should be quicker. Especially when there's not so many developers in the beginning (our team started with 2 backend and 1 frontend developers only). And there's not so many things that you can break :)

So we have started working that way. But at a certain point you stop developing the product just for sake of developing it. You're getting your first customers and sometimes its getting hard to deliver full feature in few commits. And we felt that we didn't want to go back to the old flow. This felt so much more productive.

Then I reminded myself that there was the answer in the Async Remote book. But before we get there, and see how we can use the azure feature management from the title to keep that flow, let's establish few things.

Let's establish few things

Before you stop reading and think we're crazy because we work without reading each others code or what not, I want you to know one thing. No branches and no Pull Requests is not equal to No Code Reviews. No. We do review each others code. And also, when someone is in doubt, there's a possibility to do the PR. The thing is, it's not mandatory. You can do that when you feel that you need colleagues input before you commit to the master branch. No hard rules. Just guidelines that you follow.

Find the right tool that suits your needs

I am not against branches. Do whatever works for you and your team. I've worked like that for quite some time. But the other way feels way more productive. No offence :)

All right, so we have that established. Let's see how Azure Feature Management can help us :)

The problem

The problem that we're trying to solve with Azure Feature Management is the fact that it sometimes might be hard to commit entire feature within one commit into the master branch, and then deploy it to production. It could mess few things up.

In our case it was the frontend view that has to be invisible conditionally. But it could be different. For example, you might want to change parts of backend code - introduce easily switchable branching with feature toggling. Azure Feature Management would also help you there.

The idea of solving the problem using Feature Management

So to solve this problem we can use Feature management (aka Feature Toggling) in Azure. Azure Feature Management allows you to disable parts of the code that aren't ready. Or hide those parts, if we're thinking about an UI feature.

What I really like about Feature Management in Azure is the fact that you can set it up in a way that the feature can be available only at certain time window or only for certain percentage of users.

Setting up Feature Management in Azure

Setting up the Feature Management in Azure is quite simple. Find the App Configuration resource and follow the steps in the wizard. If you get into trouble, visit this link for more detailed guidance.

Setting up the Feature Management in Azure is quite simple. Find the App Configuration resource and follow the steps in the wizard. If you get into trouble, visit this link for more detailed guidance.

App Configuration in Azure

Then in the operations section there's Feature Manager option

Feature manager in Azure

Now you can create feature flags :)

Setting Feature flags

Feature flags have option to use feature filters. However this is out of scope of this post.

C# implementation

So now as we have feature management set in the Azure, we can implement it in C#. To solve our problem, we'll create an endpoint that returns list of currently enabled features. Then, the frontend client will be able to manipulate the view and navigation based on the result.

Necessary packages

Let's start with packages. The packages that you should install are

Microsoft.FeatureManagement.AspNetCore, Microsoft.Azure.AppConfiguration.AspNetCore

Program.cs configuration

To enable Azure Feature Management extend your Host builder by highlighted lines (the ConfigureAppConfiguration extension)

        .ConfigureWebHostDefaults(webBuilder =>
            webBuilder.ConfigureAppConfiguration((hostContext, config) =>
                var settings = config.Build();
                var connection = settings.GetConnectionString("AppConfig");
                config.AddAzureAppConfiguration(options =>
Enter fullscreen mode Exit fullscreen mode


Simply Add Feature Management :)


The Endpoint for Frontend

The endpoint is simple and uses configured Azure Feature Management SDK to manage App Configuration connection. The frontend client gets all the available features with a field describing whether it's enabled or not.

    public class FeatureManagementController : Controller
        private readonly IFeatureManager _featureManager;

        public FeatureManagementController(IFeatureManager featureManager)
            _featureManager = featureManager;

        /// <summary>
        /// Returns feature flags that are set up for the application
        /// </summary>
        /// <returns>List of feature flags. Feature flag contains name and status (enabled or not)</returns>
        public async Task<IActionResult> GetFeatureFlags()
            var featureFlags = new List<Feature>();
            await foreach (var featureFlag in _featureManager.GetFeatureNamesAsync()) // Fetches all Feature names from Azure 
                 // IsEnabledAsync method call returns the value from App Configuration, Feature Management tab for desired feature flag.
                featureFlags.Add(new Feature(featureFlag, await _featureManager.IsEnabledAsync(featureFlag)));

            return Ok(featureFlags);
Enter fullscreen mode Exit fullscreen mode

The using that allows you to use IFeatureManager interface:

using Microsoft.FeatureManagement;


  • Azure Feature Management lets you enable and disable certain parts of code
  • There's dedicated SDK that makes it easier to fetch available feature flags and their status
  • Azure Feature Management is available through App Configuration service on Azure
  • Because of feature flags, it's possible to commit and push that is not yet ready to be used by an end user
  • It's also possible to manipulate who gets the certain feature enabled by using feature filters, which is out of this blog post scope

Have you ever tried Azure Feature Management? What's your opinion on that?

Top comments (0)