If you’re familiar with using modern CD tools, such as Harness CD, you are probably also familiar with canary releases. Canaries let you serve a new version of your app to a subset of your total traffic in the production environment, learn how it’s working, and then cut more traffic over to the new version safely in a progressive way. Feature Flags also let you turn something on for a subset of your users, then ramp it up over time in a safe and progressive way! So, a question we get a lot as a company that sells great software for continuous delivery with canaries and Feature Flags is: what’s the difference?

Not Versus. AND. 

The first thing we always say is, this is a great question and may take a few minutes to unpack. And, the second this is - it’s not feature flags vs canaries, it’s feature flags and canaries. 

One way to think of CD + Feature Flags in the software delivery process is as a ladder, where CD builds on CI and Feature Flags builds on CD. Using canaries for your deployment strategy and feature flags for your release strategy is additive - and we recommend it.

When to Canary

Canary releases help you change artifacts in your environment. They make sure the new version of your application is running safely, handling traffic, and doing what you need to see metrics-wise before you fully rely on it. 

Canaries are great for backend and infrastructure-focused changes - as well as to even get the features into prod that you want to start testing - that every deployment contains. The goal of a canary is always to get the new version to 100%, and ideally, to do so as fast as you can.

Canaries, though, are not about testing new features, running beta programs, or having toggles around changes that you will want to target in precise ways or have to persist for longer periods of time. This is where feature flags come in.

When to Flag 

Feature Flags are focused after your deployment. Feature Flags let you do two primary things:

• Turn on changes, or new features, for a specific subset of your audience (such as location, beta group, or individual users) in a controlled way. This is perfect for beta testing, getting feedback on new features, as well as testing the impact of changes without deploys and rollbacks.
• Maintain operation toggles around things you may want to turn on or off occasionally - such as turning off caching during peak times. Feature Flags are an easier, more visible, and auditable way to have these kinds of operational toggles.

Feature Flags allow for precise, ad-hoc targeting around any dimension you want - target your users by location, plan, individual customer name - anything you can think of that you may want to use for targeting changes.

Conclusion

With Canaries + Feature Flags, you can roll your deployments out and verify that the new code is working, producing good metrics, and not creating havoc in a progressive way - and, on top of that, roll features and changes out to targeted users, or cohorts of users, over time as part of your beta process, experimentation process, or selective feature enablement needs.

This gets you true progressive delivery, both progressive on the deploy and after the deploy, with full control over what you release, when, and to whom.

If you’d like to learn more about Feature Flags, we wrote a great post about what they are and how to use them - it’s a great starting point in your FF journey! If you haven’t signed up to use Harness yet but want to get started, you can easily sign up for free forever or request a demo. Happy developing!