Code

Canary releases (also “canary deployments”) and feature flag rollouts are two common feature release strategies for testing in the production environment, increasing the safety of continuous delivery, deploying faster and more often. Both aim to reduce the “blast radius” of unforeseen problems and build confidence in a new release. Both…

Product teams that don’t take into account a user communication and user feedback collection strategy as part of their experiments risk not getting enough data to evaluate results. This article walks through a couple key communication steps that products should follow to ensure effective and timely product experiments.

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.

Following up from the excellent post by Pete Hodgson on Retiring Your Flags, and his presentation at the Meetup we recently sponsored, I wanted to dive into how Split plays a role in managing your flag debt. Feature flags (aka toggles, flips, gates, or switches) are a software delivery concept…

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.

The concept of Serverless Computing, also called Functions as a Service (FaaS) is fast becoming a trend in software development. This blog post will highlight steps and best practices for integrating Split feature flags into a serverless environment.

Feature flags are a necessary part of your Continuous Delivery (“CD”) pipeline. In fact, as your team grows, you can’t do CD without feature flags. This article provides best practices on when to use feature flags.

Since joining Split, it has been clear that feature testing is the fundamental building block of our software development process. We deploy unit tests to validate discrete parts of business logic, end-to-end tests to monitor our APIs, automated usability testing to maintain our user experience, and entire network of bots…