Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2025-08-09 13:47:13 +02:00
Code Issues Projects Releases Wiki Activity

Apply review suggestions

Browse Source
This commit is contained in:
melindafekete 2025-07-28 12:48:10 +02:00
parent 6ebbf2fae1
commit a3a363e220
No known key found for this signature in database
2 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/lib/openapi/util/openapi-tags.ts
View File

@ -144,7 +144,7 @@ const OPENAPI_TAGS = [
{
name: 'Unleash Edge',
description:
'Endpoints related to [Unleash Edge](https://docs.getunleash.io/reference/api/unleash/edge).',
'Endpoints related to [Unleash Edge](https://docs.getunleash.io/reference/unleash-edge).',
},
{
name: 'Unstable',

27
website/docs/feature-flag-tutorials/use-cases/organize-feature-flags.mdx
View File

@ -45,11 +45,16 @@ The unified flag model in Unleash offers several key advantages:
Every project in Unleash contains a set of environments. You should create a set that mirrors your development and release pipeline.
A typical setup includes:
- **Development**: For local developer machines or shared development servers.
- **Testing**: For automated tests and manual QA.
- **Staging** (or pre-production): A production-like environment for final validation.
- **Production**: The live environment serving end-users.
When you configure an environment in Unleash, you define two properties:
- **Name**: A custom, human-readable name of your choice. This should match the environment in your workflow, such as `dev`, `qa`, or `live`.
- **Type**: One of four predefined options: `development`, `test`, `pre-production`, or `production`. This environment type is important for [flag lifecycle](/reference/feature-toggles#feature-flag-lifecycle), helping you improve your workflows and flag cleanup.
| Release phase/name | Purpose | Name in Unleash | Environment type |
|--------------------|--------------------------------------------------------|-----------------|--------------------|
| Development | Local developer machines or shared development servers | `development` | `development` |
| Testing | For automated tests and manual QA | `testing` | `test` |
| Staging | Production-like environment for final validation | `staging` | `pre-production` |
| Production | Live environment serving end-users | `production` | `production` |
The power of environments is that a single feature flag exists once within a project, but its state and configuration can be different in each environment.
@ -60,10 +65,6 @@ For example, the flag `new-dashboard` can be:
This separation is critical for safety. It allows developers to work freely in development without impacting production, lets QA teams create specific testing scenarios, and gives product teams fine-grained control over the production rollout.
Each environment you create is assigned one of four environment types: `development`, `testing`, `pre-production`, or `production`.
These types are not just labels; they directly influence a flag's automated [lifecycle](/reference/feature-toggles#feature-flag-lifecycle) tracking in Unleash, helping you identify features that are stuck in development or flags that have become technical debt and need to be cleaned up.
## Design your project setup
Every feature flag in Unleash must belong to a project. A new Unleash instance includes a default project, but creating custom projects is essential for scaling effectively.
@ -157,7 +158,7 @@ Unleash provides two levels of access control:
### Environment-specific permissions
A key capability for enterprise governance is the ability to define custom project roles with environment-specific permissions. This allows you to precisely control what actions a user can take in each environment.
A key capability for enterprise governance is the ability to define [custom project roles](/reference/rbac#custom-project-roles) with [environment-specific permissions](/reference/rbac#root-permissions). This allows you to precisely control what actions a user can take in each environment.
For example, you can create a "Developer" role that allows a team member to freely create and modify activation strategies in the `development` environment but only allows them to submit a change request for the `production` environment.
This workflow empowers developers to innovate quickly in safe environments while ensuring that all changes to production are subject to a formal review and approval process.
@ -288,10 +289,10 @@ Remember these core principles:
## Frequently asked questions (FAQs)
**How can we synchronize flag configurations between a staging and production environment?**
**How can we synchronize flag configurations between different environments?**
The recommended workflow is to manually reconfigure the flag's activation strategies in the target environment (e.g., production). This intentional step serves as a final safeguard.
For Enterprise users, the "clone environment" feature can bootstrap a new environment.
For your day-to-day workflow, you typically configure the flag's activation strategies in each of the target environments manually.
If you want to bootstrap a whole new environment, you can clone an existing environment and tweak the flag configurations as needed.
For full automation, you can use the Unleash API to build scripts that read the configuration from a source environment and apply it to a target.
**Can I restrict a user's access to only one environment within a project?**