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!