Feature flags MVC
What does this MR do?
This introduces a simple Feature Flags backend as part of Operations.
This exposes Unleash compatible API that can be consumed by Unleash clients.
This is a minimal implementation that fulfils the above goal, and only allows to create/edit/destroy feature flags, and fetch them with clients.
Assumptions implemented
- This introduces a new DB model:
Operations::FeatureFlags
tied to project to have a list of all features, and enabled/disabled, - This introduces a new DB model:
Operations::FeatureFlagsAccessToken
to provide an interface to be able to create additional access token to use feature flags by clients. Currently, we implicitly always create single access token when presented form, - This only allows enabling/disable FF,
- This create separate scope for client APIs (consumed by Unleash)
/api/v4/feature_flags/projects/:id/unleash/...
. The idea behind doing that via/api/v4/feature_flags/
is that this endpoint can later be served under separate domain doing simple forward proxy. The User API will have to be put in/api/v4/projects/:id/feature_flags/:ff_id
, - This requires us to securely store access token (there is separate MR for that purpose), it will be integrated once done,
- Features-as-a-code (https://gitlab.com/gitlab-org/gitlab-ee/issues/6220#note_93521369) can be freely implemented on top of that, and this approach does not deny that,
- We do not track usage of feature flags yet, this is MVC. There's a long discussion in https://gitlab.com/gitlab-org/gitlab-ee/issues/6220,
- This implementation is made in mind that
Unleash
is just a provider, that can be changed to something more suitable once we identify that.
Further improvements
- Use Object Storage to preserve configurations,
- Keep tracking of features being used (metrics?),
- Use features-as-a-code: https://gitlab.com/gitlab-org/gitlab-ee/issues/6220#note_93521369,
- Tie features with environments, keep track what environments use what flags.
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.
Screenshots
See https://gitlab.com/gitlab-org/gitlab-ee/issues/6220 for latest mockups. The below represent the current screenshots from development:
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added -
Tests added for this feature/bug - Conform by the code review guidelines
-
Has been reviewed by a UX Designer -
Has been reviewed by a Frontend maintainer -
Has been reviewed by a Backend maintainer -
Has been reviewed by a Database specialist
-
-
Conform by the merge request performance guides -
Conform by the style guides -
If you have multiple commits, please combine them into a few logically organized commits by squashing them -
Internationalization required/considered -
End-to-end tests pass ( package-and-qa
manual pipeline job)
What are the relevant issue numbers?
Edited by 🤖 GitLab Bot 🤖