10 Apr 2018

Launched: Segments, Separate Your Users Into Reusable Segments

One of the core benefits of the LaunchDarkly feature management platform is the ability to target end-users on a granular level. This means you not only have control over when a feature is ‘on’, but can decide who will see/experience it. Teams using LaunchDarkly use targeting rules to perform beta releases, canary launches, test in production, or even manage entitlements like tiered pricing structures.

We’ve gotten feedback that teams often want to target the same group of people for multiple different features. Unfortunately this meant building that list of targeting rules each time for each flag. So to make that process easier, we’ve introduced a new feature called Segments that allow you to build a list of targeting rules that can be used for different feature flags.

Segments are great for dark launchers who are targeting the same group of users for different features. This can be users of a particular technology (e.g. all of your Gmail users), a long-lived beta testing group, a particular department within your organization–you get the idea. Segments makes it easier to consistently reach particular groups that you work with over time. To use this new feature, existing LaunchDarkly customers should make sure you update your SDK (you can read more about that here).

How does this work?

In this example, I describe a set of users called Gmail Users with email addresses ending with @gmail.com.

Then, in a feature flag called Use Rich Formatting for Email I add a rule to include Gmail Users in the list of users receiving this feature flag value.

In another feature flag called Encourage Users to Switch to Gmail I add a targeting rule to  exclude Gmail Users.

That’s all there is.

How are Segments different than Prerequisites?

Our more advanced dark launchers might have noticed that segments appear very similar to prerequisites. Just remember: segments allow you to target users by key or attributes, and prerequisites represent a dependency on a flag value served to a user.

How do I get this new feature?

If you created an account starting March 1, 2018, you have already Segments. Congratulations! If you joined before that, then use of Segments requires that you update your server-side SDKs (you can read more about that here). For specific requirements, see our documentation for building user segments. Contact us at support@launchdarkly.com if you think your application is ready to handle Segments.

27 Mar 2018

Launched: Redesigned Environment Switcher

LaunchDarkly projects make it easy to manage feature flags from all of your software projects in one place. And thanks to environments, you can more easily manage your feature flags throughout your entire continuous delivery pipeline—from local development, to QA, staging, and production.

As your company grows, so do the number of projects and environments. We heard feedback from customers that it can be difficult to navigate between environments of the same project, or even between environments in different projects. Another frequently-heard problem is that not everyone cares about all projects and environments in the same account.

Today we’re excited to launch our vastly-improved environment switcher. It’s now easier find any environment you’re looking for, no matter how many projects or environments you have. Select a project on the left to find all its environments on the right. Click an environment on the right to switch over to it.

We’ve also introduced favorites. Clicking the star on an environment will toggle whether that environment is a favorite or not. And, if you have any favorites, they’ll be listed by default, so you can quickly navigate to the environments you work with the most.

01 Mar 2018

Privacy Shield and GDPR

In today’s age, where your data goes and how it is used is a new, clear, and present danger that we all face. At LaunchDarkly, we believe that the your information is yours and not ours, and the information that you have about your customers should never be used in a way that they or you did not intend. We’re pleased to announce that LaunchDarkly is amending and expanding our Privacy Policy to be US Privacy Shield and General Data Protection Regulation (GDPR) Compliant.

I’m Tim Wong, the Data Protection Officer here at LaunchDarkly, and I would like to tell you about what how things are changing. First of all, we’re making the commitment to never sell data in LaunchDarkly to third parties, so long as LaunchDarkly exists. Our customers pass their information to us in confidence and the Service Data that we collect will stay that way.

Secondly, we adhere to all of the guiding principles of the GDPR that will go live in the end of May. That includes the right to be forgotten, the right to know what data we have, and to not process data without consent. We submitted to having an independent third party audit our security/data protection/audit capabilities.

We’re also committing to creating a trust site that tries to be clear about where we stand in plain (as we can have) English and to provide a clear English changelog should our policies ever change.

We understand that data, privacy, and GDPR is important to our customers and we look forward to partnering together moving forward. If you have any concerns, questions, and especially cookies to forward us (not the digital kind), please email me at privacy@launchdarkly.com

17 Jan 2018

Launched: SOC 2 Type II Certified

This week we are happy to announce that we have achieved SOC 2 Type II certification. You may recall that last year we worked with an independent auditor to receive our SOC 2 Type I report. There are actually two kinds of SOC 2 reports—Type I and Type II.

What’s the Difference?

Type I reports on whether the systems are suitably designed. Providing an overview of the systems a SaaS platform has in place to satisfy the Trust Principles it’s being audited on. This type of report looks at your company and your procedures to determine whether they are designed to do the job you say they do. For instance, does your service correctly control access the way you say it does? However, a Type I report doesn’t take into consideration how well these actually work in practice—for that, you need a Type II report.

Type II reports look at the actual outcomes of the system and if it’s operating as designed. The report audits how well your software, team, and procedures worked with actual data within the evaluated timeframe. Were there any significant service outages? Were there any security incidents? Was the data handled effectively? Did your service effectively manage features for the allotted time, 6 months in our case, the auditors evaluated your system?

Type II Is All About CONSISTENCY

The Type II reports are what your customers really want. When a customer is trusting your service to run a portion of their business, they want to see proof your system operates effectively over the long term. And enterprise organizations like working with products that conform to the highest standards of the AICPA and that your practices back up your promises.

With a SOC 2 Type II report, you can provide customers evidence that you accomplish what you claim. You can show that external auditors have agreed that the control systems you have in place work as you say they do, and were observed over an extended period. This is not just about closing a deal, this is a key part of establishing trust that our customers can feel confident they can pass along to their customers.

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.

10 Jan 2018

Launched: Private User Attributes

Today we are launching a new feature called Private User Attributes. This feature allows our customers to collect event data from feature flag evaluation while controlling which user attribute fields are stored or exposed in other parts of the LaunchDarkly user interface.

In our feature management platform we use the stream of flag impression events generated by our SDKs to power many useful features—including attribute autocomplete, our users page, the flag status dashboard and A/B testing. Some of our customers have requirements to restrict Personally Identifiable Information (PII) from being sent to LaunchDarkly. Until now, these customer’s only choice had been to completely disable any event data that might contain PII fields (emails, user names, etc.).

The introduction of Private User Attributes means all customers now have the the ability to selectively choose not to send back some or all user attributes. With this selective approach, customers can continue to view flag statuses, use A/B testing, and view and override attributes for targeted users while protecting sensitive data. We have also made several small changes to the LaunchDarkly web UI to display when attributes are not available and offer reasonable choices when data has been marked as private and is unavailable for display.

What is a Private User Attribute?

When a user attribute is declared private it can continue to be used for targeting but its value will not be sent back to LaunchDarkly. For example, consider the following targeting rule:

if e-mail endsWith "@launchdarkly.com" serve true

To implement this in your application, you’d make this call to LaunchDarkly:

ldclient.variation("alternate.page", {
  key: "35935",
  email: "bob@launchdarkly.com"
}, false)

When this code is executed, a flag impression event would be sent back to LaunchDarkly containing the following data:

  {
    "key""alternate.page",
    "kind""feature",
    "user": {
      "email":"bob@launchdarkly.com",
      "key""35935"
    },
    "value"true
  }

In the example above, LaunchDarkly has received the email address of a user. Suppose now that you want to target by email address but not send that personally identifiable address back to LaunchDarkly.

This is what private attributes are for—you can mark the email field ‘private’. If your application marks the email field private, you can still target by email address but LaunchDarkly will receive the following data:

  {
    "key""alternate.page",
    "kind""feature",
    "user": {
      "key""35935",
      "privateAttrs": ["email"]
    },
    "value"true
  }

This data object no longer contains the targeted user’s email address. Instead, there is a record that an email attribute was provided during feature flag evaluation but that its value has been excluded from the event data.

Ok, let’s hide some stuff.

There are three different ways to configure private attributes in our SDKs:

  • You can mark all attributes private globally in your LDClient configuration object.
  • You can mark specific attributes private by name globally in your LdClient configuration object.
  • You can also mark specific attributes private by name for individual users when you construct LDUser objects.

It should be noted that the user key attribute cannot be marked private, for this reason we encourage the best practice of not using any PII as the user key. For more in-depth docs you can look at the SDK Reference Guides.

How do private attributes work for mobile and browser SDKs?

You might recall that our mobile and browser SDKs work slightly differently—flags are evaluated on LaunchDarkly’s servers, not in the SDKs. We still support private user attributes for these SDKs; when evaluation happens, we do not record any data about the user being evaluated. For analytics events, these SDKs strip out private user attributes the same way our server-side SDKs do, so your data is still kept private.

How will marking attributes private affect my experience?

At LaunchDarkly usability is critically important to us (after all, we use LaunchDarkly to build LaunchDarkly). In thinking through the impact of reducing the amount of data that is visible we wanted to still provide an intuitive UX for existing features. Because we record the name—but not the value—of a private attribute, name autocomplete will continue to function for private attributes in the UI, but autocomplete will not be offered for attribute values. We also indicate which attributes on a user are marked private on the User Page and when we are unable to predict a user’s Flag settings because a targeting rule uses a private attribute. Below is an example of the User page for a user with attributes marked as private:

Why shouldn’t I just make ALL my attributes private?

Making all your attributes private would limit some of the product features that rely on having attribute values available. For example:

  • The UI will not offer to autocomplete values. You’ll be able to see the names of hidden attributes, but not their values. So you’ll know that (e.g.) “email” is available for targeting, but you won’t know (in the UI) what email addresses exist.
  • Flag settings (on the users page) won’t be exact. We’ll be able to know if the user has a specific setting enabled, but we won’t be to predict what variation a user is receiving because we won’t be able to evaluate the targeting rules when hidden attributes are in play.

Given these limitations, our recommendation is that you selectively use Private User Attributes only for the purpose of securing PII.

We’d like to thank all the customers that provided feedback on this feature, we hope you enjoy not sharing your data.