Skip to content

Commit

Permalink
Update and restructure environments
Browse files Browse the repository at this point in the history
  • Loading branch information
melindafekete committed Oct 21, 2024
1 parent c170580 commit ecc85fb
Show file tree
Hide file tree
Showing 17 changed files with 34 additions and 119 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -238,7 +238,7 @@ export const EnvironmentCloneModal = ({
modal
title={`Clone ${environment.name} environment`}
description='Cloning an environment will clone all feature flags and their configuration (activation strategies, segments, status, etc) into a new environment.'
documentationLink='https://docs.getunleash.io/reference/environments#cloning-environments'
documentationLink='https://docs.getunleash.io/reference/environments#clone-an-environment'
documentationLinkLabel='Cloning environments documentation'
formatApiCode={formatApiCode}
>
Expand Down
2 changes: 1 addition & 1 deletion src/lib/routes/admin-api/environments.ts
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ export class EnvironmentsController extends Controller {
operationId: 'getProjectEnvironments',
summary: 'Get the environments available to a project',
description:
'Gets the environments that are available for this project. An environment is available for a project if enabled in the [project configuration](https://docs.getunleash.io/reference/environments#step-1-enable-new-environments-for-your-project)',
'Gets the environments that are available for this project. An environment is available for a project if enabled in the [project configuration](https://docs.getunleash.io/reference/environments#enable-an-environment)',
responses: {
200: createResponseSchema('environmentsProjectSchema'),
...getStandardResponses(401, 403, 404),
Expand Down
39 changes: 0 additions & 39 deletions website/docs/how-to/how-to-clone-environments.mdx

This file was deleted.

103 changes: 27 additions & 76 deletions website/docs/reference/environments.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,112 +8,63 @@ title: Environments
**Version**: `4.3+`

:::
## Overview

<div style={{position: 'relative', paddingBottom: '56.25%', height: '0'}}>
<iframe src="https://www.loom.com/embed/95239e875bbc4e09a5c5833e1942e4b0" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style={{position: 'absolute', top: '0', left: '0', width: '100%', height: '100%'}}></iframe>
</div>
Environments represent different stages in your development lifecycle. They allow you to manage your product releases from local development to production. [Projects](/reference/projects) and [feature flags](/reference/feature-toggles) are accessible in all environments, but each environment has different configurations. This allows you to enable a feature flag in development or test without enabling it in production.

Environments are a way to organize activation strategy configurations for feature flags. A feature exists in all environments, as the goal is to release it as soon as possible, but it makes sense to configure activation differently depending on the environment. [Open Source](https://www.getunleash.io/pricing) and [Pro](https://www.getunleash.io/pricing) customers have two preconfigured environments, **development** and **production**. [Enterprise](https://www.getunleash.io/pricing) customers can have unlimited environments.
The default environments are **development** and **production**. Unleash instances created before version `4.3` also have an environment called **default**. [Enterprise](https://www.getunleash.io/pricing) customers can create, clone, deprecate, and delete environments.

Connected applications use environment-scoped API keys to ensure they download only the relevant feature flag configurations for the environment they are running in. Unleash tracks usage metrics per environment.

![A graph showing how environments work. Each project can have multiple features, and each feature can have different activation strategies in each of its environments.](/img/environments_overview.svg 'A feature flag exists across all environments, but take different activation strategies per environment.')
The set of all available environments is defined at the instance level. Additionally, each project can choose which of the environments are visible on the project level. The set of environments available to any given project is always a subset of the environments at the instance level. Each project must always have at least one active environment.

## Environment types

All environments in Unleash have a **type**. When you create a new environment, you must also assign it a type.

The built-in environment types are:
Each environment has a name and one of the following types:
- Development
- Test
- Pre-production
- Production

The **production** environment type is special: Unleash will show additional confirmation prompts when you change something that could impact users in environments of this type. The built-in "production" environment is a production-type environment.

The other environment types do not currently have any functionality associated with them. This may change in the future.
Environments of type production show additional confirmation prompts when making changes that may affect users. The default **production** environment is of type production.

## Global and project-level environments
## Activation strategies

Environments exist on a global level, so they are available to all projects within Unleash. However, every [project](./projects) might not need to use every environment. That's why you can also choose which of the global environments should be available within a project.
[Activation strategies](/reference/activation-strategies) are the component of feature flags that define who should get a feature. An activation strategy is assigned to one feature flag in one environment. For example, you can use activation strategies to show a feature only to select users in development, but roll it out to 25% of users in production.

## How to start using environments
![Figure demonstrating the relationship between projects, environments, feature flags, and activation strategies](/img/environments-activation-strategy.png)

To enable an environment for a feature flag, you must first add activation strategies for that environment. You cannot enable an environment without activation strategies.
## Connected applications and usage metrics

### Step 1: Enable new environments for your Project
When connecting an SDK to Unleash, the API key determines which environment to fetch feature flag configurations for. Therefore, connected applications must use environment-scoped [API tokens](/reference/api-tokens-and-client-keys).

Navigate to the project and choose the “environments” tab.
:::caution deprecation

![A project view showing the Environments tab. The UI displays three environment flags: "default", "development", and "production". The "default" environment is enabled.](/img/environments_configure.png 'Configure environment for this project')
The `environment` context field in SDKs is a legacy implementation and does not affect environment access.

### Step 2: Configure activation strategies for the new environment

From the “feature flag view” you will now be able to configure activation strategies per environment. You can also enable and disable environments here. Remember that an environment must have activation strategies before you can enable it.
:::

![A feature flag strategies tab showing three different environments, of which one is active. The UI displays data about the currently selected environment, ](/img/environments_strategies.png 'Add strategy configuration per environment')
Unleash tracks usage metrics per environment.

### Step 3: Create environment specific API keys
## Enable an environment

In order for the SDK to download the feature flag configuration for the correct environment you will need to create an API token for a defined environment.
To enable an environment for a feature flag, you must first add [activation strategies](#activation-strategies) for that environment. If you don't define an activation strategy, the default is a gradual rollout to 100% of users.

![An API key creation form. The form's fields are "username", "token type", "project", and, crucially, "environment". The development environment is selected.](/img/environments_api_keys.png 'Create Environment specific API Keys')
To enable a feature flag in a specific environment, do the following:
1. In the Admin UI, navigate to the feature flag you'd like to enable in an environment.
2. In the list of environments, click **Add strategy** for the environment you want to enable.
3. Enter a strategy name and define the rollout percentage. Optionally, you can configure segments, constraints, and variants.
4. Click **Save strategy**.
5. In the **Enabled in environments** section, toggle the environment you want to enable.

## Cloning environments
## Clone an environment

:::note Availability

**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.19+`

:::

Unleash environments can be cloned. Cloning an environment creates a **new** environment based on the selected source environment. When cloning an environment, you select any number of projects whose feature flag configurations will also be cloned. These projects will have identical configurations for the source and target environments. However, the environments can then be configured independently and will not stay in sync with each other.

When cloning an environment, you must give the new environment
- a name
- an environment type
- a list of projects to clone feature configurations in

You can also clone user permissions into the new environment. When you do that, permissions in the new environment will be the same as in the environment you cloned from. If you don't clone permissions, only admins and project editors can make changes in the new environment. You can change permissions after creation by using [custom project roles](../reference/rbac#custom-project-roles).

In order to clone an environment, you can follow the [how to clone environments](../how-to/how-to-clone-environments.mdx) guide.

Once created, the new environment works just as any other environment.

## Migration

To ease migration we have created a special environment called **default**. All existing activation strategies have been added to this environment. All existing Client API keys have also been scoped to work against the default environment to ensure zero disruption as part of the upgrade.

If you're currently using strategy constraints together with the “environment” field on the Unleash Context, you should be aware that the new environment support works slightly differently. With environments, the SDK API will use the client's API key to determine which environment the client is configured for. The API then sends _only_ strategies belonging to the client's environment. This means that you might not need the "environment" property of the Unleash Context anymore.

![A strategy constraint using the environment field of the unleash context.](/img/environments_strategy_constraints.png 'You will not use strategy constraints for environments any more.')

### Integrations

We have made some slight changes to events related to feature flags: there's one deprecation and several new event types. Most of the new events contain _project_ and _environment_ data.

To avoid missing important updates, you will also need to update your integration configuration to subscribe to the new events.

**Deprecated events:**

- **FEATURE_UPDATE** - _not used after switching to environments_

**New Events**

- **FEATURE-METADATA-UPDATED** - The feature flag metadata was updated (across all environments).
- **FEATURE-STRATEGY-ADD**¹ - An activation strategy was added to a feature flag in an environment. The _data_ will contain the updated strategy configuration.
- **FEATURE-STRATEGY-UPDATE**¹ - An activation strategy was updated for a feature flag. The _data_ will contain the updated strategy configuration.
- **FEATURE-STRATEGY-REMOVE**¹ - An activation strategy was removed for a feature flag.
- **FEATURE-ENVIRONMENT-ENABLED**¹ - Signals that a feature flag has been _enabled_ in a defined environment.
- **FEATURE-ENVIRONMENT-DISABLED**¹ - Signals that a feature flag has been _disabled_ in a defined environment.
- **FEATURE-PROJECT-CHANGE**¹ - The feature flag was moved to a new project.

> 1. These feature events will contain _project_ and _environment_ as part of the event metadata.
### API

In order to support configuration per environment we had to rebuild our feature flag admin API to account for environments as well. This means that we're making the following changes to the API:
Cloning an environment allows you to duplicate environments, including all feature flag strategies and their states. To clone an environment in the Admin UI, go to **Configure > Environments**. Under **Actions**, select **Clone** for the environment you want to clone.

- **/api/admin/features** - _deprecated (scheduled for removal in Unleash v5.0). The [old feature flags admin API](/reference/api/legacy/unleash/admin/features.md) still works, but strategy configuration will be assumed to target the “default” environment._
- **/api/admin/projects/:projectId/features** - New feature API to be used for feature flags which also adds support for environments. See [the documentation](/reference/api/legacy/unleash/admin/features.md) to learn more.
Cloning an environment creates a copy of the selected source environment. You can select which projects to clone the environment configuration in. This means that the default visibility of the source environment, as well as all feature flag configurations of the source environment, are cloned in the new environment. For example, if a feature flag had a gradual rollout to 67% in the source environment, then your new environment will have the same feature enabled with the same activation strategy in the new environment. After cloning, the environments are independent and do not stay in sync.

You can also clone the [user permissions](/reference/rbac) of the source environment. If you don't clone permissions, only Admins and Editors can make changes in the new environment.
1 change: 0 additions & 1 deletion website/sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -539,7 +539,6 @@ module.exports = {
slug: '/how-to/env',
},
items: [
'how-to/how-to-clone-environments',
'how-to/how-to-import-export',
'how-to/how-to-environment-import-export',
],
Expand Down
Binary file removed website/static/img/clone-environment-1.png
Binary file not shown.
Binary file removed website/static/img/clone-environment-2.png
Binary file not shown.
Binary file removed website/static/img/clone-environment-3.png
Binary file not shown.
Binary file removed website/static/img/clone-environment-4.png
Binary file not shown.
Binary file removed website/static/img/clone-environment-5.png
Binary file not shown.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file removed website/static/img/environments_api_keys.png
Binary file not shown.
Binary file removed website/static/img/environments_configure.png
Binary file not shown.
1 change: 0 additions & 1 deletion website/static/img/environments_overview.svg

This file was deleted.

Binary file removed website/static/img/environments_strategies.png
Binary file not shown.
Binary file not shown.
5 changes: 5 additions & 0 deletions website/vercel.json
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,11 @@
"destination": "/reference/feature-toggles#set-a-naming-pattern",
"permanent": true
},
{
"source": "/how-to/how-to-clone-environments",
"destination": "/reference/environments#clone-an-environment",
"permanent": true
},
{
"source": "/toggle_variants",
"destination": "/reference/feature-toggle-variants",
Expand Down

0 comments on commit ecc85fb

Please sign in to comment.