Article summary
Feature flags are an essential part of continuous delivery for a software development team. At their most basic, feature flags are toggles that can be used to switch a feature on or off at runtime without changes in code. With feature flags, developers can effectively hide a new feature behind a binary switch until the feature is ready for release. Feature flagging also allows more gradual feature rollouts by environment, region, or user pool.
Sounds simple, right? However, maintaining feature flags can get complicated quickly. In my current project, we began implementing feature flags by storing them as environment variables. This worked fine for a while. We had a small set of flags that were set at deployment time for each environment.
However, this was not a long-term solution. As the team size and the project complexity grew, it became clear we needed a way to improve our feature flag process. Thus, we worked out a clear set of goals to improve our future flagging. In this post, I’ll describe my team’s goals in flagging and why we chose AWS AppConfig to meet our needs.
Team Goals
We need a central location to store and document flags.
Our project encompasses numerous applications, each with multiple environments. This adds up fast. With this ever-growing project landscape, it became harder and harder to keep track of all possible combinations of flags and the current settings for each environment.
At best, this creates confusion; but at its worst, this can cause unexpected behavior and runtime failures. To quell these concerns, we needed a central location for storing and documenting flag states. This way, we could easily view settings for all applications and environments in a single place and understand the impact on app behavior.
We need a way to toggle features quickly.
This was the most obvious issue. Instead of adding a flag in multiple places in our codebase, setting values for all environments, and waiting for flags to be updated at deploy time, we needed a way to set flags independently and have them affect runtime behavior immediately.
We need a way to keep track of long-term vs. short-term flags.
We had a problem. The number of feature flags on our project was constantly increasing. Flags lived on forever, long after a feature was fully deployed. As the number of flags on the project grows, regular flag maintenance became a necessity. Once a feature is deployed in all environments, the flag is no longer needed. It should not be hanging around.
On the flip side, some feature flags are long-term circuit breakers that act as a fail-safe, allowing a particular area of the application to be completely shut off. For example, we may choose to shut off a set of non-essential features when the application is experiencing periods of particularly high traffic.
AWS AppConfig
Flags can be stored and accessed in a myriad of ways. Services such as Launch Darkly, Harness Feature Flags, and Unleash (along with countless others) promise to make feature flagging easy. So, what made AppConfig the right solution for our team?
Since we already use AWS for our project, integrating with their services seemed like a no-brainer. Setting up AWS AppConfig in our project was relatively simple. AWS stores our flag values, and our applications can read them at runtime. But does AppConfig meet all of our team’s goals?
We need a central location for storing and documenting flags.
Check. Instead of storing flag configurations as environment variables in various applications and repositories, AppConfig allows us to create a central AppConfig application for flag storage. We can then separate profiles for each of our applications with environments representing our various deployed environments (development, testing, production, etc.). It also includes flag descriptions for easy documentation.
We need a way to toggle features quickly.
Check. AWSAppConfig allows individual feature flags to be toggled on and off in the AWS console. The deployment process allows for either incremental or immediate rollouts of new flag configurations. This means our team can deploy new configurations practically instantaneously.
We need a way to keep track of long-term vs. short-term flags.
Check. AppConfig allows flags to be marked as short-term with a deprecation date, so it is easy to see when a flag is hanging around longer than intended. Then we can perform the necessary cleanup.