We have updated our Data Processing Addendum, for more information – Click here.

Feature Flag Retirement

Contents

Removing Old Flags and Technical Debt

In today’s modern development, you can’t live without feature flags. They allow developers to move faster with less risk. For product teams, feature flags are indispensable because they allow for safe experimentation with new or existing features. Whether for faster feature delivery or continuous experimentation, they unlock better experiences for users while reducing costs and increasing competitiveness for companies.

But, unlike diamonds, most feature flags are not forever. They follow a lifecycle. First, they get created in Pre-Production during the development of a new feature. Later, they’re 100% Released, where they’re no longer needed for the same purpose. This cycle usually happens over the course of several weeks depending on the release frequency of an organization.

A common pain-point among organizations is tech-debt caused by feature flags that have reached the end of their life cycle. If feature flags are not removed from code once they’ve reached the end, their presence causes several issues:

  • For one, every feature flag makes the code a tiny bit harder to read, understand, and maintain. The reason for this is because feature flags add a level of complexity to the code. Developers waste time trying to understand dead code (i.e. code that never gets executed) when they’re dealing with code that contains flags that are 100% Released.
  • Even if a feature is 100% Released and turned on for customers, sometimes not all of the tests are updated to be in the On state. Furthermore, sometimes new tests fail to add the feature flag which will put them in the Control or Off state by default. So new tests could even be testing the Off state. This means that the tests aren’t actually testing the same code that customers are using. In this scenario, a bug could be introduced without being noticed, despite strong test coverage.

There is an easy way to identify which feature flags can be removed from code. Simply look for ones that have been in 100% Released status for at least 100 days. Once these flags have been identified, their owners can be informed to remove them from code. The Split Admin API is perfectly suited to automate this process via a script. Let’s dive in!

How Split Can Automate Removal

First, the List Splits endpoint is used to list all flags in a certain Workspace. Expect the endpoint to return this response:

{
  "objects": [
    {
      "name": "sample_feature",
      "description": "A sample feature to help you learn how split works.",
      "id": "0000cea0-8f4d-11e7-b345-491559441642",
      "trafficType": {
        "id": "6414eaa0-8f4d-11e7-b345-124259445f48",
        "name": "user"
      },
      "creationTime": 1504294821336,
      "tags": [{ "name": "one tag" }],
      "owners": [
        {
          "id": "ff88ac00-ee89-11ec-adf2-72d3f125aefe",
          "type": "user"
        }
      ],
      "rolloutStatus": {
        "id": "35f71d79-0cb1-42d4-b029-5e5468c480e1",
        "name": "100% Released"
      },
      "rolloutStatusTimestamp": 1625668535289
    }
  ],
  // code...
  "offset": 0,
  "limit": 20,
  "totalCount": "N"
}
JSON

Next, the script needs to filter the response for splits that are in rolloutStatus 100% Released. The script also needs to make sure that the splits have been in that status for at least 100 days. Comparing the rolloutStatusTimestamp with the current timestamp will achieve that. For each of the splits in this filtered list, the owner id needs to be used as the input for calling the Get User endpoint. This endpoint returns:

{
  "id": "<user_id>",
  "type": "user",
  "name": "<display_name>",
  "email": "<email>",
  "status": "ACTIVE"
 // code
}
JSON

The email address in the response above can be used to reach out to the owner of a split that is ready to be retired.
Another way to find out which feature flags may be removed from code is via the Rollout Board in Split. The Split Team recently added a view called Ready to cleanup. This view will only show flags that have been in one of these statuses for at least 100 days: 100% Released, Removed from Code, Ramping, Killed.

But, we’re not stopping there! Early in 2023, we’re releasing new functionality aimed at helping teams prevent the build up of tech debt and better empower users to retire unnecessary feature flags in a timely manner.

With “Done” Notifications, users can opt in to get proactive alerts when feature flags are ready for retirement/removal. Often, a feature is considered “done” when it is released to all users or to a specific target group. To avoid the accumulation of tech debt, this is often an ideal time to retire the feature flag. So, Split users will be able to subscribe to status changes of feature flags — and also select how they want to be notified.

Stay tuned for more help & automation to clean up flags in 2023.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Switch It On With Split

Split gives product development teams the confidence to release features that matter faster. It’s the only feature management and experimentation solution that automatically attributes data-driven insight to every feature that’s released—all while enabling astoundingly easy deployment, profound risk reduction, and better visibility across teams. Split offers more than a platform: It offers partnership. By sticking with customers every step of the way, Split illuminates the path toward continuous improvement and timely innovation. Switch on a trial account, schedule a demo, or contact us for further questions.

Want to Dive Deeper?

We have a lot to explore that can help you understand feature flags. Learn more about benefits, use cases, and real world applications that you can try.

Create Impact With Everything You Build

We’re excited to accompany you on your journey as you build faster, release safer, and launch impactful products.