Allow users to create and manage feature flags for their applications (Feature Flags MVC)
Description
Feature flags enable teams to achieve CD by letting them deploy "dark" features to production as smaller batches for controlled testing, separating feature delivery from customer launch, and removing risk from the pipeline. More info on "why CD", including feature flags, can be found in this article from Eric Ries.
Alpha Feature
Since we have testing several of assumptions that we are not yet sure about for this large, important feature, this iteration should be considered as ALPHA and subject to change improve based on the feedback and further improvements. The API interface and other elements of the implementation are the subject to change, depending on our investigation how well Unleash
/this approach is behaving, and in the future we might adopt other Client or even write our own.
Proposal
For the MVC we are building a very simple implementation of feature flags. At a high level, you will be able to go into the GitLab feature flag interface and define one or more feature flags. These feature flags will have a name, enabled/disabled status, and description. Checking the feature flag will be done through an API that, for now, can only return true or false to indicate if the feature flag is enabled or disabled. Editing (including enabled/disabled status) and removing feature flags is also only done through the web interface.
This is intended to be simple and straightforward, and also lay the foundation for future enhancement in several possible directions.
This MVC is built on a simple implementation of an Unleash-compatible (though minimal) API, and includes the following specific capabilities:
- Create/edit/remove feature flag through the web interface
- Changing active/inactive will be through the edit interface
- FF will have a name, whether or not it is enabled/disabled, and a description
- Show guidance on how to connect with Unleash (i.e., modal from mocks)
- The list will be attractive and follow our designs
- Removal will use a modal
The above will be implemented with HAML.
For now, the MVC will not include the following:
- No tabs
- No requested date
- No dynamic toggle buttons (to enable/disable, edit FF and enable it via form)
- No percentage rollout (yet)
- No metrics/reporting
- No mapping of environments to flags
The above will be enough to get exposure of the feature, understand scalability and usage of the Unleash API client.
For the GitLab MVC implementation we'll be taking special care to minimize platform performance impact with this feature implementation.
Usage
- Go to
Operations > Feature Flags
, - Click add
New Feature Flag
, - Fill the name of the feature flag (
can contain only lowercase letters, digits, '_' and '-'. Must start with a letter, and cannot end with '-' or '_'"
), - Save,
- Click configure to get access credentials,
- Put the credentials in your application.
Simple application making use of credentials
package main
import (
"io"
"log"
"net/http"
"github.com/Unleash/unleash-client-go"
)
type metricsInterface struct {
}
func init() {
unleash.Initialize(
unleash.WithUrl("http://localhost:3000/api/v4/feature_flags/projects/14/unleash"),
unleash.WithInstanceId("29QmjsW6KngPR5JNPMWx"),
unleash.WithAppName("production"),
// This is due to bug with Unleash and sync call and being broken ;)
unleash.WithListener(&metricsInterface{}),
)
}
func helloServer(w http.ResponseWriter, req *http.Request) {
if unleash.IsEnabled("my_feature_name") {
io.WriteString(w, "Feature enabled\n")
} else {
io.WriteString(w, "hello, world!\n")
}
}
func main() {
http.HandleFunc("/", helloServer)
log.Fatal(http.ListenAndServe(":12345", nil))
}
Configure
fields
The meaning of -
API URL: where client has to connect to get a list of feature flags,
-
Instance ID: the unique token that identifies project and allows us to authorize the operation of getting feature flag,
-
App name: this should be user-provided content, ideally I (@ayufan) think that it should be Environment Name, thus
$CI_ENVIRONMENT_SLUG
. This might give us an option later to provide different configuration sets for different environments, based on user preference.
Mockups
List feature flags
Configure feature flags modal
Documentation links: TBD
Edits to the mockups above
List view edits:
- Icons buttons need tooltips:
Edit
andDelete
- No tabs
- no on/off switch (must click edit to turn on/off)
- removed text buttons on right and replaced with icon buttons
- Green circles in the mockup are not to be included for now (document this) Remove modal:
Delete feature flag?
Feature flag XXX will be removed. Are you sure?
[cancel] [Delete (primary red button)]
FF creation screen:
- Toggle should be a checkbox as there is no immediate saving action done as well (result should be visible on the current screen as per our upcoming ux guidelines on using toggles: https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/95)
Edit feature flag screen:
-
Similar to creation screen
-
Title should be
Edit FFNAME
-
Primary green action button:
Save changes
Empty state
- Empty state needs both configure and new feature flag buttons and will replace also the top button row. After a feature flag has been added, the page changes to the list layout.
- The graphic will be added with this merge request gitlab-svgs!131 (merged)
- Copy
Feature flags allow you to configure your code into different flavors by dynamically toggling certain functionality. More information