Harness Feature Flags is the newest addition to the Harness Software Delivery Platform. This module allows organizations to deliver features faster, with less risk.
Companies constantly develop new software features for their customers. Traditionally, these features are made available via a software deployment and become visible to all users at the same time.
As a result, every time a new feature is deployed, there is a risk that customers will have a less than stellar experience due to a poorly-implemented feature. The only way to fix a poorly-implemented feature is to immediately roll back to the prior version, or to create a fix as quickly as possible and roll forward by deploying a new version.
Within this traditional release process, many problems become apparent:
Said simply, it comes down to two things:
So how does an organization achieve higher engineering velocity without breaking existing processes, and indeed, reducing deployment risk even further?
Companies today primarily try to solve these problems by repurposing their existing release processes. This means that they’re using mature and oftentimes complex methodologies that require a complicated git branching strategy to release features piecemeal or faster. Think of trying to use a cannon to kill a fly - it can work, but it’s probably overkill. While repurposing existing tooling can compensate in some ways, it ends up being very expensive and may miss on the specific requirements for an individual feature release.
Most companies are still not using feature flags. It is still not a universally-adopted practice, although it’s on its way to being so. Clearly, repurposing existing tools is not cutting it. And so teams need to find new ways to solve the problem. Quickly.
The primary problem teams have is simply getting started fast and realizing value. Teams can get bogged down in figuring out how to start, they can design flags in counterproductive ways, and they can create future problems due to this immaturity in the beginning.
For teams who are more mature with feature flagging, there is a “best practices” and management problem. Once a team has dozens or hundreds of flags, that means there is a lot of stale code, not a lot of process for managing it, and teams often struggle operationally to deal with this as part of a healthy workflow.
For some of the most mature teams, feature flags are often closely tied to their software delivery process, but fundamentally disconnected from it due to the existing vendors all being stand-alone tools. This means teams have to invest a lot of time in wiring up feature flags with metrics systems, build systems, etc. because the tools are not integrated natively. It also introduces significant maintenance overhead to ensure all these systems continue to work together over time.
So clearly, there are working solutions out there, but it seems they all have their own problems…
Harness Feature Flags started as an internal project to use feature flags with our own software. The lessons learned from that project were applied to building the customer-facing Harness Feature Flags - everyone gets to benefit from our successes and failures.
In particular, Harness Feature Flags focuses on the following key concepts:
While there are a variety of strong feature flag solutions in the market, including in-house builds, they tend to miss the mark on some key requirements for customers. At its core, feature flags are used as software switches to hide or activate features, but Harness Feature Flags goes beyond just that basic use case:
To get started with Harness Feature Flags, just sign up for a demo and a Harness specialist will get you going.
Better yet, you’ll soon be able to get started with Harness Feature Flags in an entirely self-service manner. Check back in a couple of weeks for even more developer goodness!
You can also check out this video that walks through how Harness Feature Flags is designed specially for developers.