Requirements

Add an option to the flag to disable data export, because sometimes we don't want to export the data for a specific flag.

Depends on #82

Motivation

PayloadURL is a bad name.

Requirements

We want to deprecate PayloadURL and introduce EndpointURL instead.
We will remove PayloadURL later.

We should update the documentation in consequence.

Requirements

Some people don't like the YAML format to store the flag file.
We can ask for the support of JSON or TOML.

Motivation

Today we are checking the percentage for the feature flag as int.
It means that if you give 15.15% in your configuration it will be interpreted as 15%.

Requirements

We want to have a more fine-grained configuration with acceptance of 3 numbers after the coma.
It means that:

• 15,15% --> 15.15%
• 15,154% --> 15.154%
• 15,1545% --> 15.154%

Requirements

The AllFlagsState method captures the state of all feature flag keys with regard to a specific user.
This includes their values, as well as other metadata.

This complex result is useful to send to a front-end for them to keep the values of the flags.

Requirements

Allow having multiple flag configurations in the same service.

Observed behavior

When running the test sometimes we have a race condition detected.

==================
WARNING: DATA RACE
Read at 0x00c0003b4030 by goroutine 26:
  github.com/thomaspoignant/go-feature-flag/internal/cache.(*cacheImpl).UpdateCache()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/internal/cache/cache.go:54 +0x13b
  github.com/thomaspoignant/go-feature-flag.retrieveFlagsAndUpdateCache()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/feature_flag.go:124 +0x2a1
  github.com/thomaspoignant/go-feature-flag.(*GoFeatureFlag).startFlagUpdaterDaemon()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/feature_flag.go:100 +0x20b

Previous write at 0x00c0003b4030 by goroutine 24:
  github.com/thomaspoignant/go-feature-flag/internal/cache.(*cacheImpl).Close()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/internal/cache/cache.go:68 +0x55
  github.com/thomaspoignant/go-feature-flag.(*GoFeatureFlag).Close()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/feature_flag.go:88 +0xd2
  github.com/thomaspoignant/go-feature-flag.TestUpdateFlag()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/feature_flag_test.go:167 +0x613
  testing.tRunner()
      /usr/local/opt/go/libexec/src/testing/testing.go:1194 +0x202

Goroutine 26 (running) created at:
  github.com/thomaspoignant/go-feature-flag.New()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/feature_flag.go:78 +0x6a4
  github.com/thomaspoignant/go-feature-flag.TestUpdateFlag()
      /Users/thomas.poignant/Documents/dev/external_project/go-feature-flag/feature_flag_test.go:141 +0x357
  testing.tRunner()
      /usr/local/opt/go/libexec/src/testing/testing.go:1194 +0x202

Goroutine 24 (finished) created at:
  testing.(*T).Run()
      /usr/local/opt/go/libexec/src/testing/testing.go:1239 +0x5d7
  testing.runTests.func1()
      /usr/local/opt/go/libexec/src/testing/testing.go:1512 +0xa6
  testing.tRunner()
      /usr/local/opt/go/libexec/src/testing/testing.go:1194 +0x202
  testing.runTests()
      /usr/local/opt/go/libexec/src/testing/testing.go:1510 +0x612
  testing.(*M).Run()
      /usr/local/opt/go/libexec/src/testing/testing.go:1418 +0x3b3
  main.main()
      _testmain.go:79 +0x236
==================

Expected behavior

We should not have a race condition

Requirements

Add a kafka data exporter but this time since we are using an async system we should produce an event everytime someone is calling a variation.

Motivation

Today when you start go-feature-flag and your flag file is unreachable the module return an error and you are not able to use the module at all.
We want to add an option to override this and accept to start even if the file is unreachable.

Requirements

Add an option to be able to start the module even if the file is unreachable.
With this option we should:

• Still trying to get the flag configurations with the same PollInterval .
• Use the default values from the variation function until we have a proper configuration for the flag loaded.
• It should be transparent for the usage of the module.
• The default configuration should be to failed if the file is unreachable.

Motivation

Since experimentation is a type of rollout, we should change the place used to configure it.

Requirements

Before we had this type of configuration for the experimentation.

experimentation-flag:
  percentage: 50
  true: "B"
  false: "A"
  default: "A"
  experimentation:
    startDate: 2021-03-20T00:00:00.10-05:00
    endDate: 2021-03-21T00:00:00.10-05:00

Now we want something like:

experimentation-flag:
  percentage: 50
  true: "B"
  false: "A"
  default: "A"
  rollout:
    experimentation:
      start: 2021-03-20T00:00:00.10-05:00
      end: 2021-03-21T00:00:00.10-05:00

Requirements

Based on what we did in #70 add a new type of Exporter to export the data with a call to a webhook.
The configuration should be the same format that the one used for Notifiers

Motivation

Curently the AWS SDK is packaged even if you are not using any AWS connected function.

Requirements

The SDK should not be bundled if not used.

Requirements

Based on what we did in #70 add a new type of Exporter to export the data in S3

Motivation

The README.md is bigger and bigger with each new feature.

Requirements

We should keep the README.md but we should have a real documentation website also to be able to add as much details as needed.
The Readme should still contains all the information but with links to the documentation for more details.

Motivation

UserToJSON is not a great name since we are converting it to a map, and also we don't need to export it.

Motivation

in the PR #113 we changed the way of doing experimentation.

Requirements

We should remove the support of the old way of doing it.

Motivation

Currently go-feature-flag has an interval to 1 second by default, it is maybe a bit aggressive.

Requirements

Set the interval to 60s

Motivation

gocron has helped a lot to develop the background updater, but since the task is simple enough we can remove the dependency and manage the background task directly.

Requirements

Create a goroutine that works in the background and update the cache every X seconds.

Motivation

Using ioutil.readall can be dangerous if the file is big, so we should consider using another system to read the content in our retriever.

See https://haisum.github.io/2017/09/11/golang-ioutil-readall/ for more details.

Requirements

Replaceioutil.Readall in these places :

and

Motivation

In the PR #137 we have deprecated the field PollInterval.

Requirements

Before bumping the version to the1.0.0 we should remove this field from the Config struct.

Requirement

Each time we received the default value we want to have an error to understand why we are using the default value.

Requirements

Log every time something has changed to a flag.
The same rule as #16 applied for the logs.

Requirements

Add documentation of all the supported formats.

Motivation

As mentionned here, Config.PollInterval is an int but it will be more logical to have it in a time.Duration like every time configuration we have everywhere else in the module.

Requirements

• We should find a way of configuring the PollInterval with a time.Duration.
• Config.PollInterval should be deprecated, but should also continue working for several versions to allow easy migration.
• We should put a minimum value for the polling to avoid to consistently polling the source (~ 1 second should be a good option)
  • If below the minimum, we should use the default PollInterval duration (60 seconds)

Motivation

It is not clear how to create a new user with the builders in the readme.md

Requirements

Add more doc to explain how it works

Requirements

In version v0.9.0 the field Webhooks has been deprecated.
In a future version, we want to remove the field to avoid keeping it forever.

Requirements

Add support for opentelemetry.
The goal is to be able to track when we call the retriever to get the new value of the flag

But it could be great also to have a way to notify that a flag has changed to be able to see in your dataset that a something has changed in your app.

Requirements

Adding a version field on the flags can be great to be able to track changes.
This field should be optional.

If present it should be available in the notifiers.

Motivation

Currently, we are logging all the variations if a logger is provided.
Since this is not necessarily needed, we want to replace this with a Log exporter.

Requirements

A DataExporter that can Log with the same format as the one we have in the log.

By default we should have the same log format:

Requirements

Check if we add a new retriever to get the flags from etcd.

Observed behavior

There is a flaky test that breaks the build sometimes.
https://app.circleci.com/pipelines/github/thomaspoignant/go-feature-flag/185/workflows/1f8fa3db-9587-4129-ae8e-f027a40fa269

Motivation

aws/aws-sdk-go is a big dependencies, it will be great not to force users who don't need it to have it as dependencies.

Requirements

• aws/aws-sdk-go should be loaded only if you are using S3.
• suggestion is to replace

  go-feature-flag/config.go

  Lines 21 to 24 in cd24616

  	LocalFile string
  	HTTPRetriever *HTTPRetriever
  	S3Retriever *S3Retriever
  	GithubRetriever *GithubRetriever

  with a single field that is a Retriever FlagRetriever (where the interface is declared close by))

This will probably bring a breaking change.

Requirements

Each time we check a flag for a user we want it to be printed.
The goal is to see what was value the user gets from the flag when we checked.

Format of a log:

[<TIME>] user="<USER_KEY>", flag="<FLAG_NAME>", value="<VALUE>"

Example:

[2020-12-18T15:04:42+01:00] user="random-key", flag="unknown-flag", value="false"

• we should be able to activate this log from ffclient.Config{}.
• by default log should be deactivated.

Requirements

Experimentation flags should have a starting date and an ending date.
The flag should be usable only between these dates.

It is perfect for A/B testing purpose.

Requirements

When a flag change we want a Slack notification to be informed of the change.

Motivation

Trying to avoid to use package global variables.

Requirements

Use a singleton instead.

Motivation

Our HTTP client is using the default HTTP client which is not great because it has no timeout.

Requirements

Configure an HTTP client with a timeout set.
And we should also let users pass a context (something like Retrieve(context.Context) ([]byte, error))

Requirements

Scheduling introduces the ability for users to plan and pre-define changes to their flags and segments for future points in time. While this sounds deceptively straightforward, it unlocks the potential for users to create complex release strategies by scheduling the incremental steps in advance.

For example, you may want to turn a feature ON for internal testing tomorrow and then enable it for your ‘beta’ user segment four days later. Finally, a week later, you want to start rolling it out from 0% to 100% of your user base. Now, you can define this workflow using flag scheduling and be assured that all the steps will take effect at the specified dates and times.

test-flag:
  true: true
  false: false
  default: false
  rollout:
    scheduled:
      steps:
        - date: 2021-04-10T00:00:00.10-05:00
          rule: internal eq true
          percentage: 100
        
        - date: 2021-04-14T00:00:00.10-05:00
          rule: internal eq true OR beta eq true
          percentage: 100

        - date: 2021-05-21T00:00:00.10-05:00
          rule: "" // no restriction on who is affected by the flag
          percentage: 100

Requirements

In some situations, you might want to stop making remote calls and fall back to default values for your feature flags. For example, if your software is both cloud-hosted and distributed to customers to run on premise, it might make sense to fall back to defaults when running on premise. You can do this by setting Offline mode in the client's Config.

Add an Offline field in the config to disable remote calls.

Requirements

Package go-feature-flag with an API on top to make it usable for other languages.

• Create an API on top of the SDK.
• A docker package should also be available to use as a sidecar container.
• It should probably be in another repository.

Requirements

Add some examples with some complex query to help users to understand how go-feature-flags work.

• We should have some complex rules for example and multiple flags.
• We should refer to these examples in the README.

As I can see Retriever has got private method, so it cannot be implemented and there is no way the library can be extended. Is there any particular reason why so?

Motivation

We are missing examples for each rollout strategy

Motivation

Currently, we only use thecontext.Background() when we call an exporter.

Requirements

Since a context can be pass during the init phase we should use this context in the exporters

Requirements

Add a new possible source for configuration to get the file from Github.
The config should have:

• repository slug
• branch name
• file path
• Github token (if your file is in a private repository).

Add a FAQ to explain best practices.
We should answer questions likes:

• How do I configure a flag for an A/B test?
• How do I configure a progressive rollout of a flag?
• Why do we have a default value for the flag?
• ...

Requirements

We want a way to collect the data of which user is in which variation.

This could be written in different formats (webhook, json, csv, s3, locally ...).
Since it could represent a lot of data, we want to avoid writing data every time we have a call to the variation because it will put a lot of load on the webhook to collect the affectation choices.
We should have a mechanism that collects all the variation for the last X seconds and call the webhook with all the affectation in that period in bulk.

We should also put a limit on the number of events we get before sending the bulk.
Something like call the webhook every X seconds or if the number of events equals X.

The number of seconds and number of seconds should be a parameter.
The webhook configuration should be consistent with the webhook configuration for change in flags (see doc).

Observed behavior

There is broken link in README.md and official documentation when one click on "You can find more examples programs in the examples/ directory."

Requirements

Be notified when a flag change.
Add a system that calls a webhook when a flag is changing.

• The webhook should be configured in the ffclient.Config{} type.
• We can have multiple webhook.
• The webhook is triggered when:
  • Something has changed in the flag (anything).
  • A flag is added to the file.
  • A flag is removed.
• We should not trigger the webhook when we 1st load the file.
• The payload should contain:
  • The name of the current instance using the go-feature-flag.
  • A list of the changes.

A webhook call will look like this:

POST 
{
   "meta": {
     "hostname":"",
     "IP":"0.0.0.0"
   },
   "flags": {
     "deleted": {}, //only flag names
     "added":{}, // full flag object
     "changed":{} //  flag name + differences
   }
}

Requirements

Be able to do a progressive rollout of a flag.
We need a way of automatically increase the percentage of users in the flag during the time.

What we want is to be able to set an initial percentage and a start date, and also a complete rollout date and percentage.
During between these 2 dates, the percentage will increase smoothly until reaching the complete rollout percentage.