You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Beta Status & Lifecycle Page
* Beta status and lifecycle documentation - custom statuses
* 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.
* Update docs/platform/feature-flags/status-and-lifecycle-beta.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Enhance Feature Status and Lifecycle Documentation
This update expands the documentation on Feature Statuses and lifecycle management in DevCycle.
- Kanban view for visualizing Features by Status
- details the properties and behaviors of each Status category, and clarifies the management of custom Statuses within Project settings
* Update docs/platform/feature-flags/status-and-lifecycle.md
Co-authored-by: Kaushal Kapasi <91074031+kaushalkapasi@users.noreply.github.com>
* Update docs/platform/feature-flags/status-and-lifecycle.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update docs/platform/feature-flags/status-and-lifecycle.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update docs/platform/feature-flags/status-and-lifecycle.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update docs/platform/feature-flags/status-and-lifecycle.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update docs/platform/feature-flags/features.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update docs/platform/feature-flags/status-and-lifecycle.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* docs: add note about metrics visibility for archived features
* docs: improve wording in development status description
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Kaushal Kapasi <91074031+kaushalkapasi@users.noreply.github.com>
Copy file name to clipboardExpand all lines: docs/platform/feature-flags/features.md
+16Lines changed: 16 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,22 @@ The Feature List Page is where all of your Features can be viewed, edited, and f
28
28
29
29
Use the search input to search by Name, Key, Tag, or Description. The filters can be used to filter by Creator, Status, Type, or [Staleness](/platform/feature-flags/stale-feature-notifications). Each column header can be clicked to sort the column.
30
30
31
+
### Kanban View
32
+
33
+
On the Feature list page, users can switch between a List view and a **Kanban-style view** that displays Features grouped by their current [Status](/platform/feature-flags/status-and-lifecycle), allowing teams to quickly visualize progress across the Feature lifecycle.
34
+
35
+
36
+
37
+
In this view:
38
+
39
+
- Each column represents a Feature Status
40
+
- Each column header includes a total count of Features in each Status
41
+
- Features appear as cards within the column matching their current Status, and can be sorted within each column according to the selected sort option (for example, by name or last updated date)
42
+
- Columns are ordered based on the Status order defined in Project Settings
43
+
- Status colors are reflected in the column headers for quick visual scanning
44
+
45
+
This view is intended for high-level lifecycle tracking and workflow management. Selecting a Feature card opens the Feature detail view for configuration, targeting, and Variable management.
46
+
31
47
:::info
32
48
To view another Project's Features, use the Project dropdown on the top of the Dashboard.
In DevCycle, Features have **Statuses** which indicate their current position in the Development LifeCycle. The statuses are a succinct way to understand a Feature's state, and each status has its own unique properties.
8
+
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.
9
+
10
+
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.
9
11
10
12
## Statuses
11
13
12
-
Features in DevCycle can exist in one of three Statuses to indicate their current LifeCycle stage:
14
+
Every Feature in DevCycle always has **one Status**, which determines its lifecycle stage.
15
+
By default, DevCycle provides a set of predefined Statuses aligned to core lifecycle categories.
16
+
17
+
The default Statuses are:
13
18
14
-
-**In Progress**
19
+
-**Development**
20
+
-**Live**
15
21
-**Completed**
16
22
-**Archived**
17
23
18
-
Each status comes with its unique properties, affecting how a Feature behaves, can be interacted with, or is displayed in the dashboard.
24
+
In addition to the default Statuses, teams can define **custom Statuses** within their Project settings. This allows teams to better align Feature lifecycle tracking with their internal development and release processes while preserving DevCycle's lifecycle guarantees. Each custom Status inherits the behavior of their Category.
25
+
26
+
Status changes are **not automatic** and are always managed explicitly by the user.
27
+
28
+
---
29
+
30
+
## Status Categories
31
+
32
+
Statuses are grouped into **Categories**, which define shared lifecycle behavior.
33
+
34
+
### Development
35
+
36
+
This Category represents Features that are actively being built, tested, or prepared for release.
37
+
38
+
By default, new Features are created with the **Development** Status.
39
+
40
+
While a Feature is in Development, all Targeting rules and Variations remain editable.
41
+
42
+
This stage is typically used while work is ongoing and before a Feature is considered ready for a broader release.
43
+
44
+
Below are some examples of different Statuses that would make sense in the Development Category:
45
+
46
+
-_In Development_
47
+
-_Pending Design_
48
+
-_QA_
49
+
-_Internal Testing_
50
+
51
+
---
52
+
53
+
### Live
19
54
20
-
Status changes are not automatic and are maintained by the User.
55
+
The Live Category represents Features that are actively running in production or being exposed to users.
21
56
22
-
The following is a description of each status:
57
+
While a Feature is Live, all Targeting rules and Variations remain editable.
23
58
24
-
### In Progress
59
+
Below are some examples of different Statuses that would make sense in the Live Category:
25
60
26
-
When a Feature is created, it starts in this status. While a Feature is "In Progress," you can modify everything, have as many Variations as you'd like, and have complex targeting rules.
61
+
-_Beta_
62
+
-_Ramping_
63
+
-_In Production_
64
+
-_Live Experiment_
65
+
66
+
---
27
67
28
68
### Completed
29
69
30
-
One could consider a Feature "Complete" once it has been tested, approved, and is ready for release or has been fully released. When the User changes the status to "Complete", the Feature enters a semi-readonly state the Feature enters a semi-readonly state, limiting some editability such as restricting the addition of new Targeting Rules and Variations. Additionally, all Users will be served a single Variation.
70
+
The Completed Category represents Features that have reached the end of active development and rollout.
71
+
72
+
A Feature may be considered Completed once it has been tested, approved, and is fully released, or when no further targeting changes are expected.
73
+
74
+
When a Feature is moved into a Status within the **Completed** Category, it enters a **semi-read-only state**:
75
+
76
+
- A single **final (release) Variation** must be selected
77
+
- All Environments will serve this Variation to all users
78
+
- Targeting rules are replaced with an "All users" rule
79
+
- New targeting rules and Variations cannot be added
80
+
- Variable values may still be edited
81
+
- Environments can still be toggled on or off
82
+
83
+
When using the CLI to generate TypeScript types, Variables belonging to a Feature in the Completed Category will be marked as **deprecated**.
84
+
85
+
Below are some examples of different Statuses that would make sense in the Completed Category:
86
+
87
+
-_Ready for Cleanup_
88
+
-_All Users Enabled_
89
+
-_Stable Release_
90
+
91
+
#### Cleanup Checklist
92
+
93
+
Upon entering a Completed Status, a cleanup checklist is shown for each Variable associated with the Feature.
94
+
95
+
This checklist helps teams determine when it is safe to remove Variables from their codebase or archive them.
96
+
If a Variable is still referenced in code or evaluated in production, removing it may result in default values being served.
97
+
98
+
If Code References are enabled, additional context will be provided to assist with cleanup.
99
+
100
+
---
31
101
32
102
### Archived
33
103
34
-
The "Archived" status is designed to be the terminal state for Features that have reached the end of their lifecycle, were never implemented in code, or have become entirely obsolete.
104
+
The Archived Category represents the **terminal lifecycle state** for Features. This Category and Status cannot be edited or changed.
105
+
106
+
A Feature should be archived once it has been fully cleaned up and its Variables have been removed from the codebase.
107
+
108
+
When a Feature is Archived:
109
+
110
+
- It becomes fully read-only
111
+
- It is hidden from standard dashboard views
112
+
- Audit Logs remain accessible for historical reference
113
+
- Metrics & Reach data will not be visible on the dashboard for Archived features
114
+
115
+
Archiving Features helps keep both your dashboard and codebase clean while preserving valuable lifecycle history.
116
+
117
+
> **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.
118
+
119
+
---
120
+
121
+
## Changing Status
122
+
123
+
### Moving a Feature to Completed
124
+
125
+
When a Feature is moved into the Completed Category:
126
+
127
+
- A final Variation must be selected
128
+
- All Environments serve that Variation to all users
129
+
- Existing Environment statuses are preserved
130
+
- Targeting rules are replaced with a single "All users" rule
131
+
- Additional Variations and targeting rules are locked
132
+
133
+
### Reverting to Development or Live
134
+
135
+
Features in the Completed Category can be reverted back to an earlier Status.
136
+
137
+
When reverting:
138
+
139
+
- Previous Variations become available again
140
+
- Changes made to Variable values while Completed are retained
141
+
- Prior targeting rules are **not restored** and must be reconfigured
142
+
143
+
---
144
+
145
+
## Viewing Features by Status (Kanban View)
146
+
147
+
On the Feature list page, users can switch between a List view and a **Kanban-style view** that displays Features grouped by their current Status, allowing teams to quickly visualize progress across the Feature lifecycle.
148
+
149
+
150
+
151
+
In this view:
152
+
153
+
- Each column represents a Feature Status
154
+
- Each column header includes a total count of Features in each Status
155
+
- Features appear as cards within the column matching their current Status, and can be sorted differently by selected criteria
156
+
- Columns are ordered based on the Status order defined in Project Settings
157
+
- Status colors are reflected in the column headers for quick visual scanning
158
+
159
+
This view is intended for high-level lifecycle tracking and workflow management. Selecting a Feature card opens the Feature detail view for configuration, targeting, and Variable management.
160
+
161
+
---
162
+
163
+
## Managing Statuses
164
+
165
+
Statuses are managed at the **Project level** and apply to all Features within that Project.
166
+
167
+
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.
35
168
36
-
A Feature should be archived after it has been cleaned up and its Variables removed from the codebase. Ideally, users should have also marked the Feature as **[Completed](/platform/feature-flags/status-and-lifecycle#completed)** in DevCycle.
169
+
### Project Settings
37
170
38
-
Archiving Features helps clean up your dashboard and codebase by essentially putting the Feature into a read-only mode and hiding it from the standard dashboard views. Archived Features' Audit Logs are accessible and available for teams to review.
171
+
Statuses can be viewed and managed from the **Project Settings** page under the **Feature Statuses** section.
39
172
40
-
Feature deletion still exists; however, it is recommended that Delete only be used for mistakes. Deletion permanently removes the Feature and its Audit Log from DevCycle. Keeping archived Features will allow a team to retain valuable information about its history and hopefully in the future, will allow DevCycle to make reports on the Feature lifecycle using that information.
173
+
41
174
175
+
From this page, users can:
42
176
43
-
## LifeCycle and Changing Status
177
+
- View all Statuses grouped by Category
178
+
- Create new custom Statuses within supported Categories
179
+
- Edit existing Status names (Note: each Status must have a unique key)
180
+
- Reorder Statuses within a Category
181
+
- Assign colors to Statuses for quick visual identification
182
+
- Add a description to provide context behind what a Status represents
183
+
- Select the default Status applied when a new Feature is created
44
184
45
-
### Completing a Feature
185
+
Changes made in Project Settings take effect immediately and apply across the Project.
46
186
47
-
When a Feature is marked as "Completed," the following changes are implemented:
187
+
#### Status Categories and Rules
48
188
49
-
- Status changes to "Complete."
50
-
- A "Release Variation" must be chosen which will be served to all Users for every Environment.
51
-
- Targeting rules for all Environments will be replaced with an "All users" rule serving the selected "Release Variation"
52
-
- Previously set Environment statuses are preserved.
53
-
- Additional targeting rules cannot be added when a Feature is "Complete" and must be reverted to In Progress to do so.
54
-
- The Variables section will display only one single Variation; you may not add more Variations.
55
-
- Variable values can still be modified, and Environments can be toggled on and off.
56
-
- When using the CLI code generator to [generate typescript types](https://docs.devcycle.com/sdk/client-side-sdks/javascript/javascript-typescript#cli), any Variables that are a part of a completed Feature will be marked as deprecated.
189
+
Statuses must belong to one of DevCycle's predefined Categories.
57
190
58
-
### Cleanup Checklist for Variables
191
+
The following rules apply:
59
192
60
-
Upon completing a Feature, you will see a cleanup checklist for each Variable associated with the Feature. You’ll have the option of [Cleaning up Variables](/platform/feature-flags/variables-and-variations/variables#cleaning-up-variables) which allows you archive or keep them permanently.
193
+
- New Categories cannot be created
194
+
- Each Category must contain at least one Status
195
+
- The last remaining Status in a Category cannot be deleted
196
+
- Status labels and ordering within a Category can be modified
61
197
62
-
The details in the checklist will help you know when it's safe to remove the Variable from the Feature, or archive the Variable. If the Variable is still seen in code, or if evaluations are still seen in production, removing this Variable from the Feature could result in the Variable serving default values to Users. If Code References are enabled, additional details will be shown to inform you of where to remove the Variable from code, and variables will be marked as deprecated in code.
198
+
### Permissions for Status Changes
63
199
64
-
#### Reverting to In Progress
200
+
#### Permission Rules
65
201
66
-
The "Completed" status is reversible by clicking "Revert to In Progress."
202
+
When permissions are enabled:
67
203
68
-
- Previous Feature variations will be available again, but any new changes to Variables made while in the "Complete" status remain.
69
-
- Past targeting rules will not be restored.
204
+
- Statuses in the **Development** and **Live** Categories can be applied by any user with access to the Project
205
+
- Statuses in the **Completed** and **Archived** Categories can only be applied by users with the **Publisher** permission
206
+
- Only **Publishers** can create, and modify Feature Statuses in the Project Settings
0 commit comments