機能フラグコントロール

アクセス

GitLab Inc.が提供するステージングやプロダクションなどの環境で機能フラグの背後にある機能をオン/オフできるようにするには、Chatopsbotにアクセスする必要があります。 Chatops botは現在、https://gitlab.com やhttps://dev.gitlab.orgとは異なるopsインスタンス上で動作しています。

Chatopsのドキュメントに従ってアクセスをリクエストしてください。

プロジェクトに追加されたら、アクセスが反映されたかどうかをテストします： 

/chatops run feature --help

変更の展開

変更が環境にデプロイされたら、いよいよその機能をユーザーにロールアウトします。 変更のロールアウトの正確な手順は、変更によって異なる可能性があるため、特定されていません。 しかし、一般的には、すべての人に対してすぐに有効にするのではなく、変更を少しずつロールアウトすることを推奨します。 また、コードがデプロイされる_前に_機能を有効に_しない_ことを推奨します。 これにより、機能のロールアウトとデプロイを分離することができ、両方の影響を別々に測定しやすくなります。

GitLabの機能ライブラリ（Flipperを使用し、機能フラグプロセスガイドでカバーされています）は、ユーザーへの時間割合での変更のロールアウトをサポートしています。 これは、GitLab Chatopsを使用して制御することができます。

機能フラグ・コマンドの最新リストについては、ソースコードを参照してください。 このファイルのすべての例の前には/chatops runを付けなければならないことに注意してください。

もし「Whoops! This action is not allowed. This incident will be reported.」というエラーが表示されたら、あなたのSlackアカウントでは機能フラグの変更が許可されていないか、アクセス権がないことを意味します。

プリプロダクション・テストのための機能の有効化

機能展開の最初のステップとして、https://staging.gitlab.comとhttps://dev.gitlab.orgで機能を有効にする必要があります。

これらの2つの環境は異なるスコープを持っています。dev.gitlab.org はGitLab Inc.内部のトラフィックがある本番CE環境で、いくつかの開発やその他の関連作業に使われています。staging.gitlab.com はGitLab.comのデータベースとリポジトリのより小さなサブセットを持ち、通常のトラフィックはありません。StagingはEEインスタンスで、あなたの機能がGitLab.com上でどのように見えるか/振る舞うかの（非常に）大まかな見積もりを出すことができます。これらのインスタンスはどちらもSentryに接続されているので、機能フラグを有効にした後にあなたの機能をテストしている間、そこにあるプロジェクトに例外がないかどうか確認してください。

このようなプリプロダクション環境では、その機能が関連するステージのSlackチャンネルでコマンドを実行する必要があります。 たとえば、Monitorステージ、Healthグループで開発された機能には、#s_monitor チャンネルを使用します。

全ユーザーの25%に対して機能を有効にするには、Slackで以下を実行します： 

/chatops run feature set new_navigation_bar 25 --dev
/chatops run feature set new_navigation_bar 25 --staging

GitLab.comの機能の有効化

プリプロダクション環境で機能が有効になり、安全に動作することが確認できたら、その変更を GitLab.com（本番環境）にロールアウトすることができます。

変更の伝達

GitLab.com の機能フラグの変更には、社内の一部と連絡を取るべきものもあります。 責任を持つ開発者は、その必要があるかどうか、そして適切な連絡のレベルを判断する必要があります。 これは、その機能やどのような影響があるかによって異なります。

目安として：

  • リスクが低く、簡単にロールバックできる単純な機能については、#production](#process)で、[その機能を有効にします。
  • ユーザーエクスペリエンスに影響を与える機能については、事前に#support_gitlab-com に通知することを検討してください。
  • 下流に大きな影響を与える機能（例：Elasticsearch インデックスのオン/オフ）については、事前に#productionと調整することを検討してください。

プロセス

機能フラグを切り替える前に、GitLab.com 上で進行中の重大なインシデントがないことを確認してください。これは、#production や#incident-management Slack チャンネルをチェックしたり、インシデントのオープンなイシューを探したりすることでできます（ただし、日時は確認してください）。

インシデントが発生している最中に変更を加えることは、インシデントの診断と解決を困難にし、また、ロールアウトが問題なく行われたかどうかを評価できなくなるため、ロールアウト・プロセスがほとんど無効になってしまうからです。

疑問があれば、#production。

以下の/chatops コマンドは Slack#production チャンネルで実行してください。

機能を有効にし始めたら、最初に/chatopsコマンドを実行した Slack スレッド内で、関連する機能フラグロールアウトイシューにリンクしてください。

ある機能を25%の確率で有効にするには、Slackで以下を実行します： 

/chatops run feature set new_navigation_bar 25

これは、以下の式に基づいて機能フラグをtrue に設定します： 

feature_flag_state = rand < (25 / 100.0)

これはGitLab.comの機能を有効にします。new_navigation_bar は機能の名前です。このコマンドは全ユーザーの25%に対して機能を有効にするわけではありません。その代わり、enabled?で機能をチェックすると、25%の確率でtrue を返します。

ユーザー、プロジェクト、グループなど25%のアクターに対して機能を有効にするには、Slackで以下を実行します： 

/chatops run feature set some_feature 25 --actors

これは、以下の式に基づいて機能フラグをtrue に設定します： 

feature_flag_state = Zlib.crc32("some_feature<Actor>:#{actor.id}") % (100 * 1_000) < 25 * 1_000]
# where <Actor>: is a `User`, `Group`, `Project` and actor is an instance

開発中、機能の性質に基づいて、アクターを選択する必要があります。

ユーザー重視の機能 

Feature.enabled?(:feature_cool_avatars, current_user)

グループまたはネームスペース・レベルの機能の場合： 

Feature.enabled?(:feature_cooler_groups, group)

プロジェクトレベルの機能： 

Feature.enabled?(:feature_ice_cold_projects, project)

どのようなパーセンテージで計算すればよいかわからない場合は、以下の手順で計算してください：

  1. 25%
  2. 50%
  3. 75%
  4. 100%

各ステップの間に少し待ち、https://dashboards.gitlab.netの適切なグラフを監視します。 正確な待ち時間は異なるかもしれません。機能によっては数分で十分なものもあれば、数時間、あるいは数日待ちたいものもあります。 これは完全にあなた次第です。ただ、あなたのチームと、潜在的な問題が予想される場合はプロダクション・チームに明確に伝えるようにしてください。

機能ゲートは、アクターベースにすることもできます。例えば、最初にgitlab プロジェクトに対してのみ機能を有効にすることができます。プロジェクトは、--project フラグを指定することで渡されます： 

/chatops run feature set --project=gitlab-org/gitlab some_feature true

グループの場合、--group フラグが使用できます： 

/chatops run feature set --group=gitlab-org some_feature true

アクターベースのゲートはパーセンテージの前に適用されることに注意してください。 例えば、group/project をgitlab-org/gitlab と考え、与えられた例のフィーチャーをsome_featureと考えて、以下の2つのコマンドを実行するとします： 

/chatops run feature set --project=gitlab-org/gitlab some_feature true
/chatops run feature set some_feature 25 --actors

そうすると、some_feature は、アクタの 25% と、gitlab-org/gitlabと対話するときの両方で常に有効になります。 これは、機能フラグ開発でグループアクタを使用する場合に良いアイデアです。 

Feature.enabled?(:some_feature, group)
注：ある機能が常にオンまたはオフであることを確認したい場合、時間の割合によるロールアウトは良いアイデアではありません。 その場合、アクターの割合によるロールアウトの方が良い方法です。

最後に、この機能ができるだけ多くのケースで安定していることを確認するために、この機能フラグをグローバルに有効にして、この機能を完全にロールアウトする必要があります： 

/chatops run feature set some_feature true

これにより、機能フラグの状態が常に有効になるように変更され、上記処理の既存のゲート（例：--group=gitlab-org）が上書きされます。

機能フラグの変更ロギング

GitLab.com (production) に影響を与える機能フラグの変更は、自動的にイシューに記録されます。

イシューはgl-infra/feature-flag-logプロジェクトに作成され、機能フラグを有効にした人のSlackハンドル、時間、変更されたフラグの名前を最低限記録します。

イシューは GitLab 内部のGrafana ダッシュボードにもアノテーションマーカーとして投稿され、変更がさらに可視化されます。

イシューフォーマットの変更は、Chatopsプロジェクトで受け付けています。

清掃

変更が安定したと判断されたら、機能フラグを削除するために新しいマージリクエストを提出してください。 これにより、すべてのユーザーとセルフマネージドインスタンスがその変更を利用できるようになります。 このマージリクエストには必ず ~”feature flag” というラベルを追加してください。リリースマネージャが、その変更が機能フラグの後ろに隠されていることを認識できるようになります。 マージリクエストを安定ブランチにピックする必要がある場合は、適切な~"Pick into X.Y" ラベル (例:~"Pick into 13.0") も追加してください。さらなる詳細については、プロセスドキュメントをご覧ください。

機能ゲートがコードベースから削除されても、機能フラグがデプロイされたデータベースには機能レコードが残っています。 MRが各環境にデプロイされると、レコードは削除できます： 

/chatops run feature delete some_feature --dev
/chatops run feature delete some_feature --staging

そして、MRがprodにデプロイされた後、productionから削除することができます： 

/chatops run feature delete some_feature