Configuring Flipt for a GitOps workflow
https://github.com/organization/repository.git
.
The target of our change is a http.HandlerFunc
definition (in the file pkg/server/words.go
) with the name ListWords
.
Currently, the function uses a sorting function bubblesort
and we’re going to swap this for the quicksort
function.
bubblesort
directly, we’re going to use the Flipt Go SDK to switch this call based on the feature flag use-quicksort-algorithm
.
This flag is going to be a boolean type flag, and so we use the sdk.Evaluation().Boolean()
call to evaluate the enabled
property of our flag.
We provide this evaluation call with a request containing the flags key, an entity ID and a context map.
getUser(r.Context())
.
Our context map is going to contain a single key organization
, which is populated by a call to getOrganization(r.Context())
.
This will also return an identifier, only this time for the requesting user’s organization.
local
(local directory)git
(remote Git repository and branch)object
(object storage, AWS S3 or Azure Blob Storage or Google Cloud Storage)oci
(OCI registry storage)local
and git
backend types.
features.yml
file in the root of our existing project.
Then we will configure Flipt to serve directly from our local directory.
features.yml
and you can spread your flag
definitions across multiple files. Checkout our docs on locating flag
state to learn more.use-quicksort-algorithm
flag.
This flag will be a boolean type flag and be in a disabled (enabled = false
) state.
This image demonstrates what can be seen in the Flipt UI with the configuration file we defined being served.Now that Flipt is running locally, our application can also be run and configured to target our local instance of Flipt available at both
http://localhost:8080
and grpc://localhost:9000
(depending on your protocol of choice). The UI is also available on port 8080
, however, it’s running in read-only mode since flag state is configured via the configuration file we defined before.
local
backend is useful for experimenting and exploring flag state in your development environment.
However, in a production setting, both the git
and the object
storage types are more appropriate.
Focussing on git
, the following command runs Flipt with a remote Git repository hosted on GitHub and tracking the main
branch.
main
branch.
Changes will eventually propagate into our running instance of Flipt.
features.yml
file to our branch main
.
disabled
state.
You can use curl
to ensure the service is still behaving as expected:
features.yml
file and update the definition with a new segment and add a rollout rule on our flag which returns enable = true
when the request matches our new segment.
internal-users
Segmentorganization
on the context, with a value internal
.
Remember we added the key organization
earlier when defining the flag in code.
We used a value derived from the request (getOrganization(r.Context())
).
This got the organization identifier for the calling user.
Now, when the user happens to be associated with the internal
organization, it will match the internal-users
segment in Flipt.
enabled
property of the flag under certain conditions.
In this instance, we’re using the segment
type rule to say when the request matches the internal-users
segment, return the value true
.
Now our flag is configured to target internal users and enable the Quicksort algorithm for those users instead.
main
, Flipt will eventually start serving this new configuration change.
We can now request our application as an authenticated user.
Users inside the internal
organization should get results sorted with the new Quicksort algorithm.
Whereas, the rest of users should still be served using the old Bubble Sort algorithm.
internal
users, we can start to roll it out to external users.
flipt
binary has the sub-command flipt validate
.
This can be used to statically validate your Flipt feature configuration files.
You can install this to run during a CI step and catch bugs before merging changes into main
.For GitHub, try our pre-built Flipt Setup Action.features.yml
and add a threshold percentage rule.
value
.
If no rules match, then the flags top-level enabled
property is used as the final default return value.
20
, meaning roughly 20%
of entity IDs will match and cause the flag to return enabled = true
.
percentage
property of this newly added threshold
rollout rule.
Once we get to the stage of enabling the flag for 100% of users, we can either set the percentage to 100
or we can remove the targeting rules altogether and set the enabled
property to true
.
quicksort
function.
object
or the oci
backend if your source Git repositories are too large (we’re working on a guide for that now).
The declarative storage backends currently mandate that the UI is read-only.
We’ve thoughts on how this could change in the future, but for now, this is a limitation.
You always have your editor, Git and the SCMs (GitHub, Gitlab etc) for state management in the meantime.
Each of these backends work by polling their sources (git, oci, local directory or object store) and the interval can be configured.
Checkout the Configuration: Storage: Declarative for details on adjusting these intervals.