From a1611376973a88fc7e12b5aa066908b4f814f724 Mon Sep 17 00:00:00 2001 From: Kate MacFarlane Date: Tue, 16 Dec 2025 09:19:01 -0500 Subject: [PATCH 1/4] Beta Status & Lifecycle Page --- .../status-and-lifecycle-beta.md | 149 ++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 docs/platform/feature-flags/status-and-lifecycle-beta.md diff --git a/docs/platform/feature-flags/status-and-lifecycle-beta.md b/docs/platform/feature-flags/status-and-lifecycle-beta.md new file mode 100644 index 00000000..6603a788 --- /dev/null +++ b/docs/platform/feature-flags/status-and-lifecycle-beta.md @@ -0,0 +1,149 @@ +--- +title: Status & Lifecycle BETA +sidebar_position: 4.5 +--- + +# Feature Status and Lifecycle Management + +In DevCycle, Features have **Statuses** that indicate their current position in the feature lifecycle. Statuses provide a clear, at-a-glance understanding of where a Feature is in its development, release, and cleanup process. + +Each Status belongs to a **Status Category**, which defines how the Feature behaves, what actions are allowed, and how it is displayed across the dashboard. + +## Statuses + +Every Feature in DevCycle always has **one Status**, which determines its lifecycle stage. +By default, DevCycle provides a set of predefined Statuses aligned to core lifecycle categories. + +The default Statuses are: + +- **Development** +- **Live** +- **Completed** +- **Archived** + +Each Status has unique properties that affect how a Feature can be configured, edited, or interacted with. + +Status changes are **not automatic** and are always managed explicitly by the user. + +--- + +## Status Categories + +Statuses are grouped into **Categories**, which define shared lifecycle behavior. + +### Development + +This category represents Features that are actively being built, tested, or prepared for release. + +By default, new Features are created in the **Development** Status. + +While a Feature is in Development: + +- All Feature settings are fully editable +- Any number of Variations can be created +- Complex targeting rules are supported +- Environments can be independently configured + +This stage is typically used while work is ongoing and before a Feature is considered ready for broad release. + +--- + +### Live + +The Live category represents Features that are actively running in production or being exposed to users. + +While a Feature is Live: + +- Targeting rules and Variations remain editable +- Features may be ramped, paused, or selectively targeted +- The Feature is considered active and user-facing + +This stage is commonly used for gradual rollouts, experiments, or long-running production Features. + +--- + +### Completed + +The Completed category represents Features that have reached the end of active development and rollout. + +A Feature may be considered Completed once it has been tested, approved, and is fully released, or when no further targeting changes are expected. + +When a Feature is moved into a Status within the **Completed** category, it enters a **semi–read-only state**: + +- A single **final (release) Variation** must be selected +- All Environments will serve this Variation to all users +- Targeting rules are replaced with an "All users" rule +- New targeting rules and Variations cannot be added +- Variable values may still be edited +- Environments can still be toggled on or off + +When using the CLI to generate TypeScript types, Variables belonging to a Feature in the Completed category will be marked as **deprecated**. + +#### Cleanup Checklist + +Upon entering a Completed Status, a cleanup checklist is shown for each Variable associated with the Feature. + +This checklist helps teams determine when it is safe to remove Variables from their codebase or archive them. +If a Variable is still referenced in code or evaluated in production, removing it may result in default values being served. + +If Code References are enabled, additional context will be provided to assist with cleanup. + +--- + +### Archived + +The Archived category represents the **terminal lifecycle state** for Features. + +A Feature should be archived once it has been fully cleaned up and its Variables have been removed from the codebase. + +When a Feature is Archived: + +- It becomes fully read-only +- It is hidden from standard dashboard views +- Audit Logs remain accessible for historical reference + +Archiving Features helps keep both your dashboard and codebase clean while preserving valuable lifecycle history. + +> **Note:** Feature deletion still exists, but should only be used for mistakes. Deleting a Feature permanently removes it and its Audit Log. Archived Features retain historical data that may be used for future reporting and analysis. + +--- + +## Changing Status + +### Moving a Feature to Completed + +When a Feature is moved into the Completed category: + +- A final Variation must be selected +- All Environments serve that Variation to all users +- Existing Environment statuses are preserved +- Targeting rules are replaced with a single "All users" rule +- Additional Variations and targeting rules are locked + +### Reverting to Development or Live + +Features in the Completed category can be reverted back to an earlier Status. + +When reverting: + +- Previous Variations become available again +- Changes made to Variable values while Completed are retained +- Prior targeting rules are **not restored** and must be reconfigured + +--- + +## Custom Statuses + +In addition to the default Statuses, teams can define **custom Statuses** within their Project settings. + +Custom Statuses allow teams to better align Feature lifecycle tracking with their internal development and release processes while preserving DevCycle's lifecycle guarantees. + +Custom Statuses: + +- Belong to existing Categories +- Inherit the behavior of their Category +- Can be reordered and renamed within constraints +- Cannot change the behavior of the Archived category + +All Statuses within the Completed category follow the same completion flow and require selection of a final Variation. + From 0fecafba58dae199330767a36456b32f51077464 Mon Sep 17 00:00:00 2001 From: Kate MacFarlane Date: Tue, 16 Dec 2025 09:19:31 -0500 Subject: [PATCH 2/4] Beta status and lifecycle documentation - custom statuses --- docs/platform/feature-flags/status-and-lifecycle-beta.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/platform/feature-flags/status-and-lifecycle-beta.md b/docs/platform/feature-flags/status-and-lifecycle-beta.md index 6603a788..911c609b 100644 --- a/docs/platform/feature-flags/status-and-lifecycle-beta.md +++ b/docs/platform/feature-flags/status-and-lifecycle-beta.md @@ -146,4 +146,3 @@ Custom Statuses: - Cannot change the behavior of the Archived category All Statuses within the Completed category follow the same completion flow and require selection of a final Variation. - From f3c242cf84d09f2da8da337b788f2a43f59fb62a Mon Sep 17 00:00:00 2001 From: Kate MacFarlane Date: Tue, 16 Dec 2025 09:52:45 -0500 Subject: [PATCH 3/4] Add management section for Feature Statuses in Project Settings This update introduces a new section on managing Feature Statuses at the Project level, detailing how to view, create, edit, and reorder statuses. It also outlines permissions for status changes and the rules governing status categories. --- .../status-and-lifecycle-beta.md | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/platform/feature-flags/status-and-lifecycle-beta.md b/docs/platform/feature-flags/status-and-lifecycle-beta.md index 911c609b..0d9e6eb2 100644 --- a/docs/platform/feature-flags/status-and-lifecycle-beta.md +++ b/docs/platform/feature-flags/status-and-lifecycle-beta.md @@ -132,6 +132,48 @@ When reverting: --- +## Managing Statuses + +Statuses are managed at the **Project level** and apply to all Features within that Project. + +Each Project starts with a default set of Statuses aligned to DevCycle’s lifecycle categories. Teams may customize these Statuses to better reflect their internal workflows. + +### Project Settings + +Statuses can be viewed and managed from the **Project Settings** page under the **Feature Statuses** section. + +From this page, users can: + +- View all Statuses grouped by Category +- Create new custom Statuses within supported Categories +- Edit existing Status labels +- Reorder Statuses within a Category +- Assign colors to Statuses for quick visual identification +- Select the default Status applied when a new Feature is created + +Changes made in Project Settings take effect immediately and apply across the Project. + +#### Status Categories and Rules + +Statuses must belong to one of DevCycle’s predefined Categories. + +The following rules apply: + +- New Categories cannot be created +- Each Category must contain at least one Status +- The last remaining Status in a Category cannot be deleted +- Status labels and ordering within a Category can be modified + +### Permissions for Status Changes + +#### Permissions + +When permissions are enabled: + +- Statuses in the **Development** and **Live** Categories can be applied by any user with access to the Project +- Statuses in the **Completed** and **Archived** Categories can only be applied by users with the **Publisher** permission +- Only **Publishers** can create, and modify Feature Statuses in the Project Settings + ## Custom Statuses In addition to the default Statuses, teams can define **custom Statuses** within their Project settings. From 2eff628254db844a6329cbb0e1b6a51c87131b69 Mon Sep 17 00:00:00 2001 From: Kate MacFarlane Date: Tue, 16 Dec 2025 09:54:16 -0500 Subject: [PATCH 4/4] Update docs/platform/feature-flags/status-and-lifecycle-beta.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/platform/feature-flags/status-and-lifecycle-beta.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platform/feature-flags/status-and-lifecycle-beta.md b/docs/platform/feature-flags/status-and-lifecycle-beta.md index 0d9e6eb2..af9e693b 100644 --- a/docs/platform/feature-flags/status-and-lifecycle-beta.md +++ b/docs/platform/feature-flags/status-and-lifecycle-beta.md @@ -68,7 +68,7 @@ The Completed category represents Features that have reached the end of active d A Feature may be considered Completed once it has been tested, approved, and is fully released, or when no further targeting changes are expected. -When a Feature is moved into a Status within the **Completed** category, it enters a **semi–read-only state**: +When a Feature is moved into a Status within the **Completed** category, it enters a **semi-read-only state**: - A single **final (release) Variation** must be selected - All Environments will serve this Variation to all users