LaunchDarkly Developer Documentation

Get started in under 30 minutes.
LaunchDarkly provides feature flags as a service for Java · Python · Ruby · Go · Node.js · PHP · .NET. Control feature launches -- who sees what and when -- without multiple code deploys. Easy dashboard for phased rollouts, targeting and segmenting.
Need more help? write us at

Get Started    Documentation

Azure DevOps (VSTS)

Migrating from version 1 to version 2 of the extension

On January 5th 2017, we updated our extension to support our new V2 API, which was released alongside many new features. You can read more about these features in our migration guide.

If you were already using our extension, you will need to

  • migrate your account to V2
  • update your service endpoints which now require an account access token (instead of an SDK key) to authenticate with the new API
  • update your feature flag / work item associations by also selecting a LaunchDarkly project/environment in the UI

If you run into any problems, Contact Support and an engineer will help you complete the upgrade.

The Visual Studio Team Services extension allows you to perform controlled rollouts as part of your releases. With our extension, you can define a percentage rollout for your feature flags as part of a release task.

You can find the extension on the Visual Studio Marketplace.

1. Connect to LaunchDarkly

Like Visual Studio Team Services, LaunchDarkly supports environments, which let you manage your feature flags throughout your development lifecycle.

The first step to setting up our extension is to add one LaunchDarkly service endpoint (found under Settings -> Services in your VSTS project dashboard) to your project, so that the extension can connect to your LaunchDarkly account. We have added a new endpoint type which consists of a name, and an API access token, which can be created in your LaunchDarkly account settings. Your new token will require at least write-level access. If you're using custom roles, you may create a token with a role targeting environments and feature flags relevant to your VSTS projects.

2. Set up the rollout task

The next step is to add our rollout task to your release definitions. You'll find the task under the Deploy tab of the Add tasks dialog.

This task has three fields:

  • Account: this dictates which LaunchDarkly account to update. The menu contains all the LaunchDarkly service endpoints you configured in step 1.
  • Rollout: the percentage rollout to apply to your feature flags.
  • Flag state: controls whether to turn the flag on or off upon release. Read more.

In this example, any feature flags associated with the release will be rolled out to 10% of your users in the LaunchDarkly environment you select in the work item page.

To ensure the task can access your work items, we also need to configure authentication. This is done via basic authentication. You will need to provide a few release variables, under the Configuration tab of release page.

Version 2.1.0 changes

Version 2.1.0 of our VSTS extension includes a new major update to our rollout task (v3). The new version expects different variable names which greatly reduce the chances of clashing with your existing variables. We also require a personal access token (PAT) for authentication instead of a username and password.

If you are using v3.* of our the LaunchDarkly rollout task (introduced in v2.1.0 of the VSTS extension), we expect the following variables:

3. Associate a feature flag with a release

We added a tab to the work item page so you can track your feature flags alongside your work.

When you release to an environment, the rollout task will update any flag that was linked via a work item. This will also update the LaunchDarkly section on your release page to reflect all feature flags affected by this release.

What's next?

If you're just getting started with LaunchDarkly, we recommend you read our guide to getting started. Once you have created your LaunchDarkly account, we'll walk you through a step-by-step tutorial to get you up and running quickly.

Azure DevOps (VSTS)

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.