07 Apr

Feature Flag Transition & Setup Guide

A step-by-step guide for integrating LaunchDarkly into your app and adopting feature flagging best practices

You’re now at a decision point. You want to buy a feature flagging management solution, but you are not sure how difficult the switch might be. You either have an existing system in place or you’ve never tried feature flagging before.

The transition process is actually not as daunting as you think. In fact, it’s an opportunity to clean up technical debt, mitigate risk, and start deploying better software, faster. From start to finish, this guide will walk you through the process of successfully integrating LaunchDarkly into your development process.

1. New Team Member Orientation

  • Use the QuickStart tutorial.  Create a feature flag for the platform of your choice using the step-by-step tutorial. We provide well-documented SDKs for Java, JavaScript, PHP, Python, Go, Node.JS, .NET, Ruby, Python Twisted, iOS, and Android.
  • Install LaunchDarkly in a test app.  In the QuickStart section, select “Install an SDK”.  Use this guide to install a simple feature flag in the test app of your choice. LaunchDarkly provides “hello-world” test apps to help you get familiar.
  • Check out our documentation. It’s important to understand the LaunchDarkly fundamentals.  In LaunchDarkly, feature flags are evaluated in-memory using one of our SDKs. Our user interface (app.launchdarkly.com) lets you create feature flags and targeting rules that are streamed to our SDKs in real-time.  You pass user objects to our SDKs, which evaluate the appropriate flag values for those users in microseconds. These feature flag events are sent asynchronously to LaunchDarkly, allowing you to easily manage users via our dashboard.
  • Start targeting users and playing with percentage rollouts.  Go to your feature flag dashboard and select a feature flag (docs).
    • On the targeting tab, you can:
    • Target individual users
    • Create custom targeting rules
    • Manage percentage rollouts
    • Set a default rule
    • Set an off variation
  • Create a multivariate flag. LaunchDarkly can do more than just evaluate true and false feature flags. Create multivariate flags that have multiple flag variations. These variations can be strings, numbers, and JSON arrays/objects.

2. Select a coordinator and document the transition

Your coordinator will take ownership of the transition process.

  • This coordinator should be familiar with feature flagging best practices and serve as the primary contact between your organization and LaunchDarkly.
  • Construct a document and/or use your issue tracker to itemize the switch. This is an opportunity to implement best practices in your development and release process.

3. Separate feature flags from configuration values

Scan your application and identify your feature flags.

  • It’s important to understand what a feature flag is, and what it isn’t.
  • The primary purpose of a feature flag is to control access to a feature based on the context of a user. On the other hand, a configuration value is primarily used to configure a permanent parameter, irrespective of a user’s context.
  • Feature flag use cases
    • Roll out a new checkout flow to 1%, 10%, and 100% of your users
    • Toggle a new beta feature for your beta testers
    • Sunset a poorly performing feature
    • Manage a long-term state, like maintenance mode or subscription plans
    • Serve a new upgrade to users who live in Canada and have an Android phone
  • Configuration value use cases
    • Set the hostname for your application server
    • Set authentication credentials and settings for services and backend stores
    • Set static rate limits for your application service
    • Set a directory path for data storage

4. Clean up technical debt by removing old flags

Remove the feature flags you don’t want anymore

  • This process is an opportunity to mitigate technical debt and remove all of the clutter from the past. LaunchDarkly has flag statuses that indicate when you particular feature flags are safe for removal.

5. Identify components that you would like to flag

Now that feature flagging will be easy, you should identify components of your application or particular processes that you would like to feature flag.

  • LaunchDarkly supports both boolean and multivariate feature flags. Boolean flags return true and false, but multivariate flags can return strings, number, JSON objects/arrays. You should hold a brainstorming session where everyone can identify the existing components they would like to flag.

6. Setting up your feature flags

If you have existing flags, you can use LaunchDarkly’s REST API to import your existing flags.

  • You can also use the API to bulk create new flags or simply use the LaunchDarkly UI.

To organize and document your feature flags, LaunchDarkly lets you add a name, description, and tags to each feature flag.

  • You can also name and provide descriptions for variations
  • Your team should decide the best ways to standardize naming conventions

7. Invite your team and start releasing faster with less risk

The coordinator should onboard team members, help set up projects and environments, and ensure that permissions are properly calibrated.

  • Develop guidelines for what new features need to flagged and how you will use LaunchDarkly to practice feature flag-driven development

We’re here to help!

We want to make the transition fast, easy, and productive for you and your entire team. Contact us at support@launchdarkly.com and we will answer all of your questions, provide guidance, and help you get started.

05 Apr

To Be Continuous: How To Interview

In the latest episode of To Be Continuous, Edith and Paul examine why traditional hiring methods are failing. They discuss flaws of interviewing such as the interviewer’s bias toward pattern matching, and the impossibility of getting a true representation of a candidate through an interview setting.

They explore various forms of dysfunction observed at tech companies today and consider what it takes to build a cohesive team at a startup.

This is episode #30 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: How To Interview” »

04 Apr

We got your RBAC

How LaunchDarkly gives teams granular access and security control for their feature flag management

Enterprise companies take security and privacy very seriously: risk must be mitigated, customer privacy must be protected, and software releases must be controlled.  Feature flags are essential tools to granularly control software releases, but with great power comes great responsibility.  When you have hundreds of stakeholders using a product, you need to make sure that every team member has the exact permissions they need: no more, no less.

Powerful tools demand powerful access controls.  This means that your demoing account executive should not be able to toggle off live production features unless they are explicitly allowed to enable for a customer.  Likewise, your developers should be able to use feature flags in their own environments, but might not have access to disable functionality that customers depend on.

Custom Roles

To make this a reality, LaunchDarkly has built an extremely powerful and granular access control system that we call custom roles.

Custom roles let you control access for every team member and every feature in LaunchDarkly, from a particular flag’s percentage rollout to the ability to toggle a flag on or off.  You can create a role using our custom roles builder.

Here are some possible custom roles:

  • Lock your production environment down to a small set of trusted users
  • Distinguish infrastructure-level feature flags (controlled by your devOps team) from experiments (controlled by product management or marketing)
  • Allow QA members to control feature flags on designated QA environments only
  • Allow your designers to add users to betas
  • Allow sales to turn a feature “on” for a user

Security

Equally essential for security is the ability to prevent nefarious access and brute force attacks.  Companies want to make sure that the platform controlling their feature releases conforms to security best practices.

As such, LaunchDarkly provides multi-factor authentication and session control for all customers.  Multi-factor authentication (MFA) improves the security of your account by requiring a second verification step in addition to your password to login. In LaunchDarkly, you can enable multi-factor authentication for your team’s account, which requires you to enter a verification passcode from a free authenticator application you install on your mobile device.  You can also require all team members to enable MFA before accessing their accounts.

Moreover, LaunchDarkly’s session control offers administrators a set of controls to manage how long users stay logged in to their account, and how often they need to re-authenticate.  This allows admins to take proactive measures when an account is compromised or a laptop is lost, providing full control over LaunchDarkly account access.

Summary

Feature flagging is increasingly becoming central to a company’s software development and release lifecycles.  As part of a company’s critical infrastructure, feature flag management platforms must have enterprise-grade security to ensure that customer data is safe and that every team member has the exact access they need.

14 Mar

My Agile Launch

Starting at a company that helps software teams release faster with less risk has reminded me of my first foray into agile development.

One of my earliest professional experiences was as an intern at HBO, where I reported directly to the VP of Emerging Technologies.  Over the course of the summer, it became clear that there were more promising new technologies to explore than there were engineers.  The undaunted college student that I was, I convinced my boss that I should own one of these projects.  Every day I would demo my work on a screen in his office, and he would provide feedback.  A few weeks later the VP presented to senior management and the company officially green-lit the project.  Though we didn’t refer to it as such, that cycle was my introduction to Agile.  Yet more importantly, it was a daily routine where a non-technical business stakeholder provided direct feedback to a technical resource; an arrangement that I’ve come to realize is quite uncommon.

Working at large and small companies in a variety of engineering roles, there are two overall trends that I’ve identified:

  1. Companies often separate engineering from the business side.
  2. Most development-related failures (e.g. missed deadline, bad or buggy feature, release causing a security vulnerability, etc.) are a result of miscommunication.

Neither of these statements are profound in isolation but when coupled genuinely pique my curiosity.

Over time the broader engineering community has developed numerous tools and processes to mitigate risk.  Missing deadlines?  Use story points to measure team output (velocity) over time.  Releasing buggy features?  Try test-driven development.  Want to avoid downtime during a release?  Setup application performance monitoring in your staging environment.  While these “quality assurance” measures are not guarantees of perfection, they make development more predictable.

Problems arise when we cut corners in response to misaligned expectations.  Let’s say there’s a feature request for a relatively straightforward user enhancement.  The development team has done everything right to this point (features properly designed and scoped), but towards the end of the sprint the team finds a scalability issue with no clear path forward.  Engineering management notifies the business side of this issue and insists that there should be resolution within five business days.  Five days pass and the developers have made no progress.  Engineering rushes to fix the issue through a refactor but skips unit testing to release earlier.  Two new bugs slip into production.  Instead of working on the next sprint the development team now works to get a hotfix release out.  One unexpected event can change everything.

The separation of the business side from its engineering counterpart sets the stage for frustration and missed opportunities.  Any tool that can bridge the gap between these two groups offers immense value to an organization or a working relationship.  Cucumber, a Behavior-Driven Development test tool, empowers non-technical stakeholders to define requirements, in plain English, that double as executable test guidelines for engineers.  By regularly reviewing Cucumber test results, a business stakeholder could easily assess the current status of a project.  Nevertheless, Cucumber facilitates one-way communication and offers no clear guidance on iteration or state.

The daily iterations I had at HBO were extremely effective in moving the project forward quickly. In a perfect world we could repeat this process as often as possible with senior management to win their approval as early as possible.  What if we schedule a daily meeting with the entire senior management team and show up with a buggy build?  It would quickly become apparent that our good intentions are far less valuable than executive time.  Instead, what if we gave each one of the senior managers a version of the technology that we could push updates to over time?  What if I could focus on building features and my boss could choose and deploy the ones that he thought were ready?  What if after realizing that there was a problem with a deployed feature he could hide that feature without involving me?  LaunchDarkly does all of this at the enterprise level.

To me LaunchDarkly is about much more than feature flagging or even quality assurance; the platform empowers companies to reconnect the technical and non-technical departments in order to shorten feedback cycles with customers and make better decisions.

This mission is a game changer.

That its founders and team are all extraordinary yet humble makes the opportunity twice as appealing.

07 Mar

What Feature Flagging Management and a 4x Super Bowl Champion have in common

Recently our investors, SoftTechVC, had a panel with professional football players on “unleashing the elite” – how professional athletes need grit, determination, hustle and mental toughness to push themselves and their teams to the next level. The panel with was captivating and amazing. The pros talked about their unrelenting training schedules – the long hours not just working out, but studying game films and memorizing plays. They talked about sacrificing college parties, time with friends, time with their families, as well as injuries. Was the sacrifice worth it? Yes, they said. They were providing a better future for themselves and their families.

RonnieLott

Ronnie Lott visits SoftTechVC

After the panel, a friendly guy named Ronnie introduced himself and asked me about software development trends. I’d graduated from Harvey Mudd College, statistically amongst the worst football teams in the country, and Ronnie had graduated from USC as an All-American. Ronnie said my eyes lit up as we talked about whether software would soon be layers of AI building on AI. I said just as 20 years ago players didn’t have iPads to watch game film on, 20 years from now we’d be amazed at the technologies that software was using.

Then I wondered why football players were at a VC firm. Because they were investors in SoftTech. The money that Ronnie, his son, and the other players had hard-won on the gridiron was going on to fuel the dreams of entrepreneurs to build a better way to build software. I thanked Ronnie for his support of LaunchDarkly, and I hoped to return his trust in us. And in the meantime, as a down payment, he could have a LaunchDarkly t-shirt.
The first LaunchDarkly investors were literally myself and John, my-cofounder, putting our own money in. Then it was our colleagues who believed in us.  Even now that we have institutional investors, behind our institutions are still people, investing because they believe in us. Thanks Ronnie Lott, Malik Jackson, Duane Brown, and all the other investors in LaunchDarkly.

03 Mar

Launched: Feature Flag Variation Editing

LaunchDarkly Feature Flag Variation Editor

Feature flags are powerful when serving variations like true and false. However, they are even more powerful when you can serve variations that are strings, numbers, JSON objects, and JSON arrays — which we call multivariate feature flags.

Previously, we allowed you to create multivariate feature flags with defined variations, but we did not let you add, edit, or delete variations once they were created. Now, you can!

With support for edit variations, you can now edit feature flags after they are created.

You can now:

  • Manage pricing in an e-commerce app by serving number variations
  • Dynamically control configuration values
  • Serve hex values to control CSS styles
  • Sunset variations that are no longer necessary

Editing Variations

When you navigate to any feature flag, you will notice a new Variations tab. This is where you will be able to edit your flag’s variations.

For boolean flags, you can edit a variation’s name and description, but not the value. This is because boolean flags can only serve true and false values.

LaunchDarkly Feature Flag Variation Editor

For multivariate flags, you can now add, edit, and delete variations even after the flag is created. Moreover, you can edit any variation’s value, name, and description. Keep in mind that you cannot change the “type” of variation being served after the flag is created.

LaunchDarkly feature flag variation editor

When you add, edit, or delete a variation for a multivariate flag, the change will apply to all environments within that project. For example, if you have a feature flag called “Checkout Flow” with 4 variations: A, B, C, D and you deleted variation D, then every environment will only have 3 variations (A, B, C) for the “Checkout Flow” feature flag.

We’re excited to deliver this new feature to you and would love to hear your feedback at support@launchdarkly.com.  You can reference our docs for more info.