Pete Hodgson

Engineers are deploying half-finished features into production, and they’re doing it on purpose. They use feature flags to hide their partially completed work. You can too.

Chaos engineering involves injecting failure into production systems, as a way to proactively validate that those systems handle a degraded environment.

By pushing feature flagging metadata into New Relic, you can understand the impact of a feature change across any metric you care about, in real time.

We’ll take a quick look at using New Relic to sleuth through a production incident, and then walk through setting it up for a Spring Boot web service.

Of the teams I spoke with who are practicing Continuous Delivery, the vast majority were not practicing Continuous Deployment. Let’s explore why that might be.

There’s more than one way to succeed with Continuous Delivery. In this article we summarize four of the common tactics various organizations employ.

As our software development processes have evolved we’ve mostly said goodbye to the idea of defined product versions. Many modern product delivery teams are taking this a step further – even the concept of a “product release” is starting to fade. Instead our products are becoming a fluid, rapidly evolving set of features, assembled uniquely for any given user.

Teams working with feature flags usually come to the conclusion that a large number of active flags isn’t necessarily a good thing. While each active feature flag in your system delivers some benefit, each flag also comes with a cost. I’m going to explain those costs, such as cognitive load and technical debt, and explain how to avoid them.

Feature flagging systems can sometimes become victims of their own success. The benefits of feature flagging along with the broad applicability of the technique can lead to rapid adoption within an organization, and pretty soon the number of active flags can start to feel overwhelming. One way to keep your feature flags manageable is to introduce a categorization system.