30 Days of DevOps Day 28: Different Approaches to Exposure Control

Day 28 of 30 Days of DevOps asks us to:

Research different approaches to exposure control (for example, canary releases) and share one you have experience with or would like to try.

I’ll be honest, I had to look up a few resources to get to grips with exposure control

What approaches do you have experience with or would you like to try?

From Slack:

@tommcc89 shared

I’ve worked with feature flags before… in the end, we stopped using them. They were there purely as exposure control, rather than to lock users behind a paywall; and we became pretty happy with our processes to the point that the feature flags were an overhead we weren’t reaping the benefits of.

It was initially an appeasement tool to put the business at ease when implementing new features in CD. So we could implement something turned off, and the po + 1 or 2 users would have access to it in live. But, it meant that there are lots of “if” statements in the code, and more maintenance etc.

When we switched the flag on globally, we would also then raise a ticket to remove said flag from the codebase.

As a result, it also meant we had tests to cover scenarios for both the default configuration, and also for “beta” users (all flags on).

So an overhead on testing and development. Removing them cut the build time in half

@laurendaniels added

My company uses both canary builds and feature flags. Canaries are great for being able to direct a small amount of life traffic to test a new experience out if you aren’t ready to rollout, which lets you tear down faster. Feature flags work well for our products so we can control experiences for users. We also use Optimizely for some A/B testing.

Another user added

We A/B test aggressively (if only to get an idea of how much an feature has improved/hurt over baseline) and use feature flags. (Shoutout to https://github.com/unleash/unleash which in full disclosure I’m a contributor to.)

From Twitter we also have