先頃のブログ投稿で、GitHub Actions EngineerのAlberto Gimeno氏が、GitHubがフィーチャーフラグを利用して頻繁で安全なデプロイメントを可能にする方法を共有した。GitHubは、リスクを伴う可能性のあるすべての変更にフィーチャーフラグを利用して、必要に応じて変更をすばやく無効にできるようにしている。
フィーチャーフラグ、またはフィーチャートグルは、表示したい場合を除いて、リリース時に新しいコードをオフに切り替える手法だ。HoneycombのCTOであるCharity Majors氏は、次のように説明している:
私はフィーチャートグルの大ファンです。コードをプロダクション環境にリリースするだけで、誰もが自動的にそれを見ることを意味することがないように、デプロイとリリースを切り離す必要があります。
フィーチャーフラグを追加すると、コードの複雑さが増す。GitHubには、コードが期待どおりに機能していることを検証するためのいくつかの方法がある。開発では、フィーチャーフラグをコマンドラインから切り替えることができる。フィーチャーフラグは、自動テストで使用するためにコードを介して切り替えることもできる。プロダクション機能では、リクエストのクエリ文字列を介してフラグを切り替えることができる。
CIパイプラインについて、Gimeno氏は次のようにシェアしている
2つの異なるビルドがあります。1つはデフォルトですべてのフィーチャーフラグを無効にして実行し、もう1つはデフォルトですべてのフィーチャーフラグを有効にして実行します。これにより、自動テストでほとんどのコードパスが適切にカバーされない可能性を大幅に減少します。
Gimeno氏は、GitHubでフィーチャーフラグを使用することで、機能を段階的に操作できるようになると指摘している。次のようにシェアしている
長期間有効なフィーチャーブランチは使用していません。代わりに、フィーチャーフラグを使用することで、小さなバッチで作業できるため、多くの利点があります。
Googleは次のように指摘している:
トランクベースのアプローチの主な利点の1つは、開発ラインを減らし、小規模で頻繁なマージを行うことで、イベントのマージの複雑さを軽減し、コードを最新の状態に保つことです。
小さなプルリクエストは、変更を検証するレビューアの能力も向上する。Chris Kemerer氏とMark Paulk氏の調査によると、1時間あたり200行を超えるコードをレビューすると、レビュープロセスの有効性が低下する。Cisco Systemsのプログラミングチームに関するSmartBearによる別の調査によると、開発者は一度に200〜400行以下のコードをレビューすることができる。それを超えるとプルリクエストの問題を検出する能力が大幅に低下する。Gimeno氏は「小さなバッチは、プルリクエストで他のエンジニアがレビューしやすい」というこの発見を反映している。
Gimeno氏は、小さなプルリクエストを作成するには、事前の計画が必要であると述べている。GitHubのチームは、プルリクエストをチャンク化するために2つのアプローチを使用している。最初に、主な作業はより大きなプルリクエストで行われる。レビューの準備ができたら、メインの作業から小さなプルリクエストが抽出される。2番目のアプローチは、メインのプルリクエストを構成するブランチからブランチを作成することだ。
GitHubは、フィーチャーフラグをターゲットにする方法に柔軟性がある。最も簡単なアプローチは、個々のユーザをターゲットにすることだ。これにより、機能をゆっくりとロールアウトし、フィードバックを収集できる。データの保存方法に影響を与える変更など、それが不可能な場合は、特定のフラグに対してリポジトリ全体をオンに切り替えることができる。
彼らはまた、Gimeno氏がダークシッピングと呼んでいるものを利用している。ダークシッピング、またはダークローンチは、ユーザまたはリクエストのサブセットに対してバックエンド機能を有効にするプロセスだが、ユーザは知らないうちに有効になる。Martin Fowler氏は次のように指摘している
ダークローンチは、既存のユーザインタラクションを強化するプロセスで、ユーザが選択を行わない時に最適に機能します。
Gimeno氏は、フラグが有効になった後に残された古いコードをクリーンアップするための自動化を改善したことを示している。「後でコードを再インデントすることに加えて、if/elseステートメントなどのコードブロックを削除し、ブール式を変更することができる」スクリプトを実行する。将来的には、フィーチャーフラグが陳腐化したと見なしたときにスクリプトを自動的に実行することを望んでいる。