More memory lane content pulled from my personal blog, before it is deprecated in favour of this technical blog.

DevOps vancouver Meetup January 2019

We had a really great turnout and a vibrant meetup hosted by Andre Kaminski, featuring three topics in January 2019:

• Entropy in DevOps Teams: Andrew Rose
• The Virtues of Being T-shaped: Kyle Young
• Progressive Exposure Using Feature Flags: Willy-Peter Schaub

You can find a copy of my feature flags presentation HERE. Ping me if the link is blocked by your firewall.

Top 6 FAQs from my talk

What's DevOps and what's the link to the session?

DevOps, by Donovan Brown

Link to the January 2019 session and photos.

When should I use rings versus feature flags?

I think of a package when using the ring-based deployment model to deploy a release and a small screwdriver to "tweak" feature flags to fine-tune the release. See Deploying new releases: Feature flags or rings? for more details.

How do I manage the technical debt introduced by feature flags?

KEEP IT SIMPLE! Define technical governance to clearly define who owns the feature flags, when and how to remove feature flags and the associated technical debt, and scenarios that are suitable for feature flags. See What's the cost of feature flags? for more details.

Who owns feature flags?

Most feature flags are scoped to a business feature, backed by a business case, and delivering value, which places the ownership of the feature flag switch with the business. Some feature flags are scoped to an operational feature, which places the ownership with operations (Ops).

What do we mean with "Do not hide non-production ready code behind feature flags"?

Production ready implies hat we have met an agreed quality bar and are confident to release the feature to production. It does not mean feature ready, as we may expose a production ready minimally viable product to perform experiments and A|B testing. Risk of hiding non-production ready code behind feature flags is high - it's easy to flip a switch and expose incomplete,unstable, of security breaches by mistake.

Why the product we introduced at the meetup?

You need to investigate and create your own opinion, but here are a few highlights from our evaluation:

• It's a Software as a Service (SaaS)
• Simple administration
• Support for experimentation
• Feature flag dependency management
• Identify stale flags
• Rules to manage exposure and blast radius
• ... and much more!

Can you tell me more about circuit breakers?

Hystrix evolved out of resilience engineering work that the Netflix API team began in 2011. See A Rough Path, by Brian Harry for an example, where circuit breakers could have protected us from an Operational meltdown, caused by simply "flipping a flag".

Two epiphanies

Last, but not least, our feature flag manifesto

On our common engineering site, we have a collection of verbal declaration of intentions, motives, or views of the issuer, for processes and products.

Here is a copy of our feature flag manifesto.

The worlds of our pipelines and feature flags are likely to collide when we innovate our ability to release on demand. See you there!