consume contents

Github の feature flag について

Github blog より

コードの中に feature flag 入れている
これは、デプロイ完了時点で全員 or 一部のアクターのみに有効になる
feature flag を無効にすることで該当機能のロールバックを数秒で済むようにしている

既存機能の回収の他に新機能開発でも feature flag を取り入れている 小さい単位で開発していくことが可能。そのプロジェクトに関わっている人間のみで feature flag を有効にし確認できる

• レビューコストの最小化
• 変更が小さいほど本番導入で導入でバグを起こしにくい
• 長期間有効な機能ブランチを使用しないことで、開発中の他の機能との潜在的なマージの競合や衝突を回避できる

データモデルやテーブル変更など長くブロックされそうなものはメインPRとして出し
そこへ小さいPRをマージする

早くPRをマージしていくために、レビューの第一人者としてレビューに注力する人物を置いている

テスト方法

• 開発環境では CLI から機能フラグを切り替えできる
• 自動テストではコードの中で機能フラグの有効/無効を切り替えられる

• CI

  • すべての機能フラグ無効にして実行
  • すべての機能フラグ有効にして実行
• 本番環境ではクエリストリングで機能フラグの有効/無効を切り替えている

デプロイ戦略

• Individual actors

  • ある機能に取り組んでいる従業員にフラグを立てたり、ある機能を試している顧客にフラグを有効にする

• Staff shipping

  • 社員に対して機能を開放する

• Early access maintainers or other beta groups

  • OSS のメンテナやその他のユーザに影響を与えるような重要機能を先に試してもらってフィードバックを得る

• Percentage of actors

  • 指定した割合のアクターに対して機能を開放する

• Dark shipping

  • クエリのパフォーマンス向上などの内部的な変更のためのもの。一定割合で機能が呼ばれるようにする。

これらの戦略は、すべてUIで管理されている。 新規フラグの作成・feature flag の出荷状況などメタデータが一通り見れる。

Go の場合

build tag でコンパイルするファイル変えられる

package main

import (  
    "fmt"
    "github.com/smith-30/tagsample/entity"  
)
func main() {  
    fmt.Printf("%#v\n", 1)
    u := entity.User{}  
    u.Hello()  
}

// +build v2.0

package entity

import "fmt"

type User struct {
}

func (a User) Hello() {
    fmt.Printf("%#v\n", "v2.0")
}

// +build v2.1

package entity

import "fmt"

type User struct {
}

func (a User) Hello() {
    fmt.Printf("%#v\n", "v2.1")
}

$ go run -tags v2.0 ./main.go
1
"v2.0"

$ go run -tags v2.1 ./main.go
1
"v2.1"