Tracking feature flags in Jira with AWS AppConfig

A key element of agile software development is the team agreeing on the “definition of done.” Before completing a project or feature, the team should document acceptance criteria that must be met to consider the work complete. A project or feature is “done” when all of the acceptance criteria are met and when value is delivered into customers’ hands.

Many software teams now use feature flags to release features to customers. In this case, the feature isn’t “done” until the feature flag has been fully set to enabled for all of the intended users. AWS recently announced an integration between AWS AppConfig Feature Flags and Atlassian’s Jira. In this integration, each AppConfig Feature Flag gets tracked in Jira as a separate issue. The whole lifecycle of the feature flag, including creation, updates, turning it on, and automatic rollbacks, is tracked. Furthermore, when a feature gets cleaned up in AppConfig, it will be noted as such in Jira. This lets a team see a feature’s true definition of done, all in one place: Jira.

In this post, you’ll learn about feature flags, how you can use them, how to connect AppConfig to Jira, and some best practices for using feature flags.

What are feature flags?

Feature flags help an engineering team move faster and more safely. They give an engineering team the opportunity to manage new application behavior with a configuration flag. This strategically decouples unreleased features from the standard release process. Developers can use feature flags to limit access to new features, thereby giving a limited audience the ability to test them in production prior to global release. They can be turned on or off at runtime, thus reducing the stress of timing new feature releases and providing a kill switch in the event that something goes wrong.

AppConfig offers a solution for managing feature flags. Customers can use AppConfig to quickly create and toggle flags as well as deploy the changes in a validated, controlled, and monitored way. As an example of feature flag use, a media website may want to add a new feature: a comments section under their news articles. By using AppConfig, the engineering team can create an enable-comment-section feature flag, which toggles the visibility of the comment section on the webpage. For initial testing, the team can add an access control list as a flag attribute, thereby identifying a subset of users who have access to the comments. After releasing the flag and sufficiently testing the new feature in a production environment, the engineering team can then adjust the flag’s access control list in AppConfig to grant access to all users. AppConfig will gradually release the change, monitoring provided alarms during the deployment and rolling back the flags if an alarm sounds. All of this safely provides customer access to the new comment feature without the need for a code deployment. For more information and a more detailed example on using feature flags in AppConfig, see the Using AWS AppConfig Feature Flags post.

How teams use Jira

There are various ways that teams use Jira Software for managing their projects. Teams can manage the entire software development cycle – initial ideas, development, testing, release, maintenance, bug-fixes, and new features – within Jira.

Jira Issues, which are typically bugs, tasks, or stories, represent units of work needed to drive a project to completion, such as a bug fix or new feature implementation. Additionally, an important part of the Jira experience is the integrations that it allows with other development tools, such as Git, Slack, or email. These allow team members even further visibility at every step of the way in their development process. One such integration is the AWS AppConfig for Jira integration, which tracks the lifecycle of feature flags in Jira.

Tracking your AppConfig Feature Flags in Jira

To track your feature flags in Jira, you must download the integration from the Atlassian Marketplace. After the download is complete, select “Configure”, which should take you to a form like this:

Figure 1. Connecting your Jira Project with AppConfig

The Jira Project is the overall project to which this feature flag is related. The dropdown will show a list of your available projects, and you can choose any of them within which you would like to track your feature flags.

The Issue Type represents what kinds of issues you want AppConfig to create in the specified Jira Project. This lets you get more control over how you want your feature flags to be tracked – as tasks, stories, or even custom issue types that you create.

Then, you must specify the AWS Region, AppConfig Application, and AppConfig Configuration Profile which contain your feature flags.

The last section of the form is AWS credentials. These credentials are never stored by AWS. They are used to determine whether or not the current user has the correct access to perform certain AppConfig actions which are required for the Jira integration. Typically, you should create an AWS Identity and Access Management (IAM) Role within your AWS account with appconfig:CreateExtensionAssociation, appconfig:ListApplications, appconfig:ListExtensionAssociations, appconfig:ListConfigurationProfiles, appconfig:GetConfigurationProfile, and sts:GetCallerIdentity permissions. Then, you can use the (temporary) credentials from this role to configure your feature flags in Jira.

After successfully configuring the integration, whenever you create or update a feature flag in AppConfig or deploy it to any of your AppConfig Environments, they will appear as Issues within the Jira Project specified to AppConfig. In the following example, we have a restaurant franchise, and we’re trying to enable a delivery feature flag within certain US states. We’ve created a feature flag for this, which has additional attributes, such as the maximum delivery radius in miles, as well as a select few US state codes where this feature will be rolled out. These are tracked in Jira in an issue that looks like this:

Figure 2. Details and change log of an individual AppConfig Feature Flag inside of Jira

From the screenshot above, we can see within Jira that we’ve created and updated a delivery feature flag, as well as successfully deployed it to the beta and prod environments.

A feature like this might require visibility, not only among developers, but also other non-engineering team members. Product Managers, Marketing, and Program Management can all have visibility into the flag’s lifecycle. The AWS AppConfig for Jira integration means that there can be more transparency and communication within teams for critical processes, such as toggling their feature flags to release new features.

Best practices for using feature flags

AppConfig Feature Flags are used extensively across thousands of teams inside of Amazon. The best practices in this section come from our own experience of using them internally. We hope they can also help your team when feature flagging.

• Validate flag data prior to releasing flags. Toggling a feature ‘on’ could be as dangerous as pushing out untested code to production. You should always have safety guard rails when enabling flags. If you have a non-boolean flag like a string, number, or array, then you should add constraints and validation to check boundaries on those values prior to deploying the flag.
• Slowly roll out flags – instant flags are only for emergencies. When updating a flag, gradually roll out the update to a small percentage of your users first. You can measure the impact of that flag with that limited user set. If everything looks good, then continue rolling out the flag slowly to 100% of your users. The only instant update of a feature flag should be in a ‘break glass’ scenario – all other releases should be gradual.
• Attach an alarm during flag deployment that can automatically roll back your flags. By definition, a feature flag is a kill switch that can disable a feature if something goes wrong. Manually toggling a kill switch is helpful. However, you should also set up a monitoring alarm that will automatically roll back a feature flag when it’s triggered. This automated kill switch is another safety guard rail for feature flags.
• Keep things simple by maintaining a small number of flags. Feature flags provide flexibility and convenience to service teams. However, overusing them introduces added code complexity, confusion, and risk. To minimize the technical debt incurred by feature flags, keep a budget on the number of flags used in code.
• Promptly clean up short-term flags at the end of their lifecycle. Once a flag has served its role, remove its logical handling in code, and then delete it. Stale flags can quickly clutter a code base, and accidental toggling of a dormant flag may introduce unexpected behavior to the service. Some flags are long-term flags and can be used for operational levers, such as throttling limits. However, if a flag is short-term and associated with a launch, then clean it up quickly after your feature is launched.

Conclusion

After reading this post, you should understand at a high level the benefits of using feature flags, as well as the benefits of tracking them in Atlassian’s Jira. You should also understand how to connect AppConfig to Jira. Furthermore, you should have some best practices for using feature flags.

• Visit the Atlassian Marketplace listing for AWS AppConfig Feature Flags
• More information on using feature flags.
• How to set up AppConfig Feature Flags for Jira.
• More about AppConfig.
• More from Amazon’s CTO Werner Vogels on the practice of Continuous Configuration and feature flags.

Authors: