Configure Flipper HTTP adapter on dev.gitlab.org

Details

Now, we can smoothly connect to GitLab Feature Flag from Feature class. We should start dogfooding on a pre-production server dev.gitlab.org in order to evaluate the new architecture if it works properly

TODO

• Announce when we reconfigure the instance. Engineers cannot update feature flags during the maintaince period.
• Reconfigure dev.gitlab.org to use HTTP adapter. The URL points to a GitLab Feature Flag Server (Project) in ops.gitlab.net.
• Migrate existing flag data from local postgres to GitLab Feature Flag.
• Announce when the migration is done. Engineers can update feature flags via chatops again.

Probably, it'd better we introduce a maintenance mode in chatops for feature flags that prevents anyone to update feature flags during the term. We're already doing the same during a production incident.

Feature Flag Servers

• dev.gitlab.org ... https://ops.gitlab.net/gitlab-org/feature_flags/dev
• staging.gitlab.com ... https://ops.gitlab.net/gitlab-org/feature_flags/staging
• gitlab.com ... https://ops.gitlab.net/gitlab-org/feature_flags/production

NOTES

• Developers can change flags via Chatops or rails console (i.e. Feature.enable). You can see the strategy vs gate mapping below.
• Developers cannot change flags in GitLab's Feature Flag UI (i.e. readonly). This is because chatops has some extended features e.g. freeze all flags during a production incident. We'll likely follow this up.
• This is a part of ~Dogfooding issues.