12 Jan 2018

Launched: Comments, Adding Context to Your Actions

A key part of problem identification is knowing what changed in the system. For developers this is often accomplished with comments in code this is to remind your ‘Future Self‘ why you made the choices that you did. As we have built LaunchDarkly we have tried to follow our own best practices around naming flags with good descriptions, assigning clear owners to flags that map to specific areas of responsibility, and adding comments in our code to provide reminders on what a given flag is for.

However, as more teams using LaunchDarkly have implemented feature flag driven development practices the platform has become a crucial part of their change management process. For anyone that has experience with change management there is an acknowledgement that context matters. Standard audit logging is great to know who changed what, when; but lacks the why. In small systems or on small teams this often falls in the category of tribal knowledge, but in large systems and large organizations 30 seconds on formally documenting changes can save hours or days in the troubleshooting process.

Today, we are happy to rollout the ability to add comments on updates to flags. Now team members can have the option to add a brief comment on why a change is being made.

As we designed this feature we also thought it would be helpful to include these comments in your favorite established output path. So, when you do decide to add a little extra context folks will see it appear along with the who, what , and when sent to the audit log, through your established webhooks, slack channels, and Hipchat rooms.

If it’s for a developer, build it on top of an API

In keeping with our mantra around API-first development the new comments functionality is built on top of the REST API.  We added the ability to submit these optional comments with PATCH changes. With this launch, the Update feature flag resource supports comments, and support in other PATCH resources is forthcoming.

Here’s an example from our API docs for submitting a comment along with a JSON Patch document:

JSON
1
2
3
4
{
  "comment""This is a comment string",
  "patch": [ {"op""replace""path""/description""value""The new description" } ]
}

Oh, and one more thing

While we’re strong proponents of JSON Patch as a protocol for describing partial updates in our REST API, we’ve found that it can be pretty verbose for simple changes. We’ve added support for the JSON Merge Patch protocol to address this. Here’s an example merge patch document  that changes a feature flag’s description:

JSON
1
2
3
{
  "description""New flag description"
}

Compare that to the equivalent JSON Patch document:

JSON
1
2
3
4
5
6
{
  "name""New recommendations engine",
  "key""engine.enable",
  "description""This is the description",
  ...
}

This addition also means that you can get fancy and combine these two new features and submit a comment along with a merge patch document:

JSON
1
2
3
4
{
  "comment""This is a comment string",
  "merge": { "description""New flag description"}
}

Achievement unlocked. And now you’ll know why.

29 Aug 2016

Feature Flagging Best Practices

While there are many companies who practice feature flagging as a way to extend continuous delivery and release faster, there are just as many companies who are just starting out with the practice.  And until now, there hasn’t been a great resource for the feature flagging beginner.  Feature flagging as a concept is super straightforward, but must be implemented with diligence.  Haphazard feature flags can devastate a company, whereas well-managed flags can prevent disaster and even make your company more competitive.  


LaunchDarkly’s guide to feature flagging best practices addresses these deficiencies and provides a roadmap for better feature flag management.  While many aspects of feature flagging must be personalized to meet a particular company’s needs, the guide acquaints newcomers with how powerful feature flags can be and what they need to watch out for.  It also relays some pro tips for those who have been feature flagging for a while.  

LAUNCHDARKLY HELPS YOU BUILD BETTER SOFTWARE FASTER BY HELPING MANAGE FEATURE FLAGS AT SCALE. START YOUR FREE TRIAL NOW.

26 Aug 2016

3 Ways to Avoid Technical Debt when Feature Flagging

Feature flags are a valuable technique of separating out release (deployment) from visibility. Feature flags allow a software organization to turn features on and off at a high level, as well as segment out their base to allow different users different levels of access. However, feature flags have an (ill-deserved) reputation of “Technical Debt”. Used incorrectly, feature flags can accumulate, add complexity, and even break your system. Used correctly, feature flags can help you move faster. Here’s three easy ways you can avoid technical debt when using feature flags.

  1. Create a central repository for feature flags

Using config files for feature flags is “the junk drawer” of technical debt. If you have seven config files with different flags for different parts of the system, it’s hard to know what flags exist, or how they interact. Have one place where you manage all of your feature flags.

  1. Avoid ambiguously named flags

Give your flags easy to understand, intuitive names. Assume that someone other than you and your flag could potentially be using this flag days, months, and years into the future. Don’t have a name that could cause someone to turn it on when they mean off, or vice versa. For example “FilterUser”, when it’s off – does this mean users are filtered? or not?

  1. Have a plan for flag removal

Some flags are meant for permanent control, for example for an entitlements system. Other flags are temporary, meant for the purpose of a release only. If a flag can be removed (because it’s serving 100% or 0% of traffic), it should be removed, as quickly as possible. To enforce this rigor, when you write the flag, also write the pull request to remove it. That way, when it’s time to remove the flag, it’s a two second task.

19 May 2016

Case study: Modernizing development & controlling rollout with LaunchDarkly

The challenge

The company, a leading online real estate marketplace, sought to bring its development up to date with modern processes. To accomplish this transformation, they hired management with experience at the most idolized mega tech companies.  The first thing on the manager’s agenda? Move faster, with less risk by using a feature flagging system like the one they had built at their previous company.  

Just for some background – at this juncture, the team was doing three-week sprint cycles. They had feature branches that they would develop every three weeks and then push out. They would deploy five features at once and if anything went wrong, they’d have to roll it all back.  

Continue reading “Case study: Modernizing development & controlling rollout with LaunchDarkly” »

16 Feb 2016

Buying vs. Building A Feature Flagging System

Feature Flag Driven Development

How to use feature flag driven development effectively at your company

Before the Decision

As an engineering or product manager, your mission is to deliver quality software on time. You are looking to make your team fast, productive, and and more coordinated. Most importantly, you want your customers to love your product.

Professional developer tools are both the foundation and scaffolding for building successful products. Without team collaboration tools, issue tracking tools, IDEs, and version control systems, your team would find it challenging to release timely, high-quality software. To facilitate and improve product development, managers must inevitably decide whether to build developer tools in-house, purchase a platform, or maintain the status-quo.

Continue reading “Buying vs. Building A Feature Flagging System” »