22 Dec 2017

Launched: LaunchDarkly Streaming Architecture for .NET

What is it?

Earlier this month we released the latest update to the .NET SDK. This update included a number of enhancements, regarding the SDKs ability to propagate feature flag updates quickly and efficiently. We added support for streaming flag updates via Server-Sent Events as an alternative to polling. HTTP-based streaming is favored over polling to reduce network traffic and propagate feature flag updates faster. This also enables users to harness the power of our relay proxy with the .NET SDK.

Why did we do this?

This update significantly improves the performance of flag updates for .NET applications and enables teams to take advantage of the latest platform features. This release may also be used in conjunction with the LaunchDarkly Relay Proxy.

What does it mean for LaunchDarkly users like me?

Upgrading will not require any code changes, and the streaming strategy will be used by default. Once your code is up and running with the latest version of the .NET SDK, you’ll immediately receive the benefits, including faster feature flag updates, and less outbound network traffic. Documentation for advanced configuration options can be found here.

But I have a lot going on—what does this really mean for an enterprise customer like me?

If you’re a heavy LaunchDarkly user, with hundreds, or even thousands of SDK instances out in the wild, the changes made in the newest update will be even more beneficial. Streaming architecture unlocks relay proxy support for .NET users. With the .NET SDK set up in proxy mode, your servers can connect directly to hosts within your own datacenter instead of retrieving flag updates from LaunchDarkly’s API individually.

What should I be doing to prepare for this change? (Best practices on making the update.)

Upgrading to the most recent version is as simple as changing the dependency version of “LaunchDarkly.Client” to the most recent version in your project files and package configurations. If you’re using Visual Studio, this can be done through the NuGet package manager UI. Otherwise, the NuGet command-line interface may be used. See Microsoft’s docs for complete instructions.

As of 12/21/17, the most recent version is 3.4.0.

Is there anything else I should know?

Yes! We have more in store for our .NET SDK, including:

  • Improved performance and memory usage when storing feature flags
  • Improved logging
  • Lighter use of dependencies
  • Support for caching flag configurations via redis

What if I have questions, who can I talk to?

Reach out to the LaunchDarkly support team directly by submitting a request here.

07 Aug 2017

Growing at LaunchDarkly: An Intern’s Perspective

When I first visited LaunchDarkly back in March, I knew there was no place I’d rather be. Coming straight out of college, moving fast (and breaking some things) had become my mantra. What I soon realized was that a high-velocity release cycle doesn’t have to mean that code quality should be sacrificed. Who knew that gateing your code behind feature toggles would basically annihilate the risk of releasing faulty features to your users? I certainly did not.

Photo via Tumbler

Working to refine the Customer Success process at LaunchDarkly has taught me many things. Ranging from working with the development team to fight fires, to assisting in product design to meet customer needs, being a Dark Launcher has created a great interdisciplinary experience. Customer Success has allowed me to build a web of knowledge on how a SaaS startup works and which requirements need to be satisfied for success on all fronts.

If I had to choose the best part of being at LaunchDarkly, it would be the people here and the atmosphere they create. This summer has been a really exciting time to be a part of this team. I’ve had the chance to watch the team almost double in size. This has meant that we have had may conversations about culture and the type of company that we each want to be a part of. One outcome of these conversations was the addition of  a “Buddy Lunch” program, an initiative which aims to introduce peers to each other on a more personal level and enjoy some awesome food!

I’m happy to announce that I’m transitioning to a full-time support role here at LaunchDarkly! It feels like I’m the outcome of a feature experiment that went really well, and now I’m excited to go into production full-time.

20 Jun 2017

What’s the deal with Custom Roles?

At LaunchDarkly we believe that the ability to finely tune access controls in the fast-paced developer space is mission critical. We’ve introduced custom roles, modeled after Amazon Web Services’ IAM service, to all of LaunchDarkly’s enterprise customers, allowing admins to control permissions at a granular level. Yet custom roles are more powerful than plain access control restrictions in that they allow you to extend functions inherently reserved for engineering teams to other stakeholders in your organization.

Let’s assume your organization has the following teams: Engineering, Customer Support, Sales, and Marketing. We’ll define policies for each that allow the organization to become more efficient and less dependent on the engineering team.

Customer Success

The value of custom roles is demonstrated quite well in the case of the customer support team, so we’ll start there.

Let’s say a team member has received a support request where a specific user has reported broken functionality on a new feature that is impacting other core features and the team is scrambling to investigate. In an organization without LaunchDarkly the customer support team would have to provide the engineering team with steps to reproduce the bug and wait for them to implement a fix. With LaunchDarkly and custom roles, the support team member can disable the problematic feature for that particular user to temporarily resolve the issue, and depending on the prevalence of the issue elect to kill switch (turn off) that feature for all users.

The support team member is empowered to remedy issues in-real time. Moreover, the engineering team is no longer launched into emergency response mode; features toggled off can be resolved at a later time.

Here is a simple custom role to support that new value:

This custom role would also be useful to sales team member, allowing that stakeholder to turn a feature on or off for a specific user based on customer plan selection. It’s less likely that the sales team would need access to the kill switch, so we would remove that in this case:



The marketing team can also benefit from custom roles. Let’s say the team wants to A/B test  a new logo or design assets. Without LaunchDarkly and custom roles, the marketing team would have to coordinate this process with engineering releases. With LaunchDarkly and custom roles, engineering could implement flagged features to allow them to do this on their own schedule and tag the features with a marketing tag. This tag could be used to identify marketing features and also double as a custom role requirement.

When the marketing team is ready to run the A/B tests, it has full control over the features and goals with that marketing tag, relieving the engineering team of the burden of supporting marketing once it has implemented the features. The engineering team can move on to exciting new features while the marketing team tests and analyzes its theories.

This marketing role is also very easy to create:


Defining custom roles for the engineering team is probably the least interesting topic in that custom roles don’t quite offer this group anything it didn’t have before. Nevertheless, we can use roles to avoid destructive operations that might affect other team members or end-users.

Imagine a scenario where a flagged feature exists in a production environment and a developer accidentally deletes that flag. An action like this would disable the feature for all end-users. Ideally we would restrict this permission to designated decision-makers.

For this purpose, we’ve created a slightly modified version of the built-in “Writer” role which does not allow for deletion of resources:

For a full list of resources and actions, and more details about the policy creation process, check out our custom roles documentation.

03 May 2017

Integrating Feature Flags in Angular v4

A little while ago, we blogged about eliminating risk in your AngularJS applications by leveraging feature flags. Like all good web frameworks Angular continues to release new versions providing opportunities to tweak and update your code. The benefits of Angular over its predecessor include a built-in compiler,type enforcement, and a complete re-write in Typescript. All valuable of updates for reducing agony within the software development lifecycle.

If you’re thinking of making the switch to Angular, or are already using it, LaunchDarkly is here to help you eliminate the risk all the way from your initial migration to future successful launches. In this article, we’ll discuss how to eliminate risk and deliver value in your Angular project.

We’ll build on Tour of Heroes (which we’ll refer to as TOH from here on out), a demonstrative Angular app which showcases the framework’s basic concepts. Essentially, TOH is a live roster of superheroes, including search functionality and the ability to modify hero details. To learn more about TOH, and to get familiar with Angular, check out the official tutorial.

Creating our Feature Flags
Suppose we want to limit the usage of our search and modify features to a certain subset of our users. To achieve this, we’ll create two feature flags, toh-search  and toh-modify . In our case, we’ll allow logged in users access to search, and only the administrator will be able modify heroes.

An implementation of toh-search in the LaunchDarkly console


Now, we’ll create a service which handles everything LaunchDarkly’s JavaScript SDK will throw at us. Note: for simplicity, we use a dummy user-switching feature (located in the user component of the project folder).

LaunchDarklyService’s constructor starts by initializing the SDK, and follows up by calling the built-in on method, which will update the feature flag values within our app whenever the user is changed, or the feature flag configurations are modified. This is handled by a Subject-typed variable,   flagChange , which will later be subscribed to by in the app’s components.
With our service functional, we’re now able inject it as a provider into TOH’s “search” and “hero” components, granting them full access to our feature flags!

In the hero-search component, we subscribe to the aforementioned flagChange , which will let Angular know that the search component should be toggled whenever the respective feature flag configuration is changed. The hero component is modified in a similar fashion to introduce the toh-modify  flag.

See it in action!



Be sure to check out the complete project on GitHub, we’d love to see what other features you can build into Tour of Heroes!