Using Feature Flags in Azure DevOps for Controlled Feature Release and Feedback

Azure DevOps technical director Buck Hodges (with translator Zhou Wenyang) describes how the team manages feature releases by separating application deployment from feature activation, allowing fine‑grained control down to individual users and avoiding exposing unfinished functionality.

The primary goals are to decouple deployment from feature rollout, prevent mandatory exposure of new code, and achieve flexible on/off control, enabling early feedback and rapid rollback without redeploying services.

Key objectives include: (1) separating deployment and feature release, (2) obtaining user feedback as early as possible, (3) enabling quick feature disablement, and (4) supporting feature toggling without a new deployment.

Feature flags (also called feature switches) are simple conditional checks in code; when a flag is enabled the new logic runs, otherwise the old logic executes.

Example XML definition of a feature flag used by VSTS services:

<?xml version="1.0" encoding="utf-8"?>
<!-- Register TFS specific features and set their states -->
<ServicingStepGroup name="TfsFeatureAvailability">
  <Steps>
    <!-- Feature Availability -->
    <ServicingStep name="Register features" stepPerformer="FeatureAvailability">
      <StepData>
        <Features owner="TFS">
          <Feature name="SourceControl.Revert" description="Source control revert features" />
        </Features>
      </StepData>
    </ServicingStep>
  </Steps>
</ServicingStepGroup>

At runtime, the flag state can be checked in code. The following TypeScript snippet shows how a button is added only when the flag is enabled:

private _addRevertButton(): void {
  if (FeatureAvailability.isFeatureEnabled(Flags.SourceControlRevert)) {
    this._calloutButtons.unshift(
      Dialogs.revertPullRequest(
        this.props.repositoryContext,
        this.props.pullRequest.pullRequestContract(),
        this.props.pullRequest.branchStatusContract().sourceBranchStatus,
        this.props.pullRequest.branchStatusContract().targetBranchStatus
      )
    );
  }
}

Feature flags can also be managed via an internal web UI, allowing per‑user or per‑tenant activation without code changes.

When a problem is detected, the flag can be turned off instantly, rolling back the feature without redeploying the application.

Testing considerations: new code behind a flag is deployed disabled by default; both the new and old paths must be tested to ensure smooth rollback if needed.

The release process is divided into stages:

Stage 0 – Canary: limited internal accounts, manual notification.

Stage 1 – MVPs & selected customers: Microsoft MVPs and early adopters, notified by email.

Stage 2 – Private preview: selected customers test the feature.

Stage 3 – Public preview: feature available to all customers with a “preview” label.

Stage 4 – General Availability (GA): feature fully released with support.

Feature flags enable unfinished features to reside on the master branch without affecting production, but they require careful security review.

They also help keep the master branch active, allowing continuous integration and faster delivery, though they increase testing effort because both old and new code paths run simultaneously.

Old flags should be cleaned up after a feature is fully released to avoid accumulation.

Real‑world example: at Connect 2013 the team mistakenly enabled many flags simultaneously, causing a service outage; lessons learned led to a policy of running flags in production for 24 hours before a major event.

In summary, feature flags in Azure DevOps provide:

Separation of deployment and feature release.

Granular, per‑user control.

Early feedback collection.

Rapid rollback capability.

Ability to toggle features without redeploying.

Support for working on the master branch.