Getting started with release pipelines

Overview

This guide explains what factors to consider when you implement release pipelines in an existing LaunchDarkly project. A release pipeline tracks the progression of a feature flag across a series of phases, where each phase consists of one or more environments. You can use release pipelines to view the status of ongoing releases across all flags in a project, enforcing a standardized process and ensuring they are following best practices. Only LaunchDarkly Owners or Administrators can configure release pipelines to track releases. To learn more, read Release pipelines.

Prerequisites

To use this guide, you should understand:

• What release pipelines are. To learn more, read Release pipelines.
• Who the Owner or Admin of your LaunchDarkly account is. To learn more, read LaunchDarkly's built-in roles.

Best practices for implementing release pipelines

First, consider who in your organization should be able to define the phases of a release pipeline, and the criteria for moving a flag from one phase to the next. These tasks are typically the responsibility of a senior engineering team member, such as a team lead or director. A senior product contributor, such as a head of product, may also be appropriate.

Next, consider who should supervise the release pipeline as flags advance through different phases. The product manager in charge of delivering a new feature would be an appropriate person to supervise that feature's release pipeline.

The first time you set up a release pipeline in your LaunchDarkly project, use the opportunity to reinforce your existing best practices. You might use a release pipeline to align LaunchDarkly environments and release pipeline phases with your current release process. To do this, consider who a flag should be targeted to and what code it affects. For example, you could advance a flag that controls access to a new feature through "Dev," "QA," "Beta release," and "Generally available" phases.

You should also consider how you will know a flag is ready to move between phases. What qualifies a flag to move out of the "QA" phase and into the "Beta release" phase?

After a release is complete, archive the flags associated with it. To learn more, read Archiving flags.

Best practices for multiple release pipelines

You can create multiple release pipelines to separate releases for different groups, or to run simultaneous efforts in parallel. For example, if you have two release processes that are very different, you may want to create one release pipeline for each process.

If you want to set up more than one release pipeline, consider which parts of your organization's work are affected by the flags and environments moving through the release pipelines. Different teams may want to have their own release pipelines for different product areas.

If you do this, it may be helpful to standardize on the name and number of phases in your organization's release pipelines. Doing this will give a consistent view of the release processes as flags move between phases.

Considerations that affect flags in release pipelines

Flags in release pipelines can move forward and backward between phases. It should always be easy to tell what the criteria are for moving a flag to a previous phase. If a flag in the "Beta release" phase reveals serious bugs in a limited-release feature, you can and should regress that flag to the "QA" or "Dev" phase, rather than proceeding with a more extensive release. Define these criteria as a team and document them, so everyone understands when and how to make these decisions.

Conclusion

In this guide, you learned best practices for implementing release pipelines across your organization, and how to think about flags as they move through the different phases of release pipelines.