Web アプリケーションのリリース プロセスの合理化: 機能フラグを使用したトランクベースの開発

この記事では、トランクベースの開発と環境ベースの機能フラグを中心に構築された、Web アプリケーションの堅牢かつ効率的なリリース プロセスについて概説します。この方法論により、高品質の標準を維持しながら、継続的な統合、運用環境での簡単なテスト、開発からリリースまでのスムーズなパスが保証されます。

---

基本原則

1. トランクベースの開発:

   • trunk ブランチは、すべての開発作業の 唯一の信頼できる情報源 として機能します。
   • 開発者は、新機能または Jira チケットのトランクから機能ブランチ (feature/xyz など) を作成します。
   • プル リクエスト (PR) は、テストが成功した後のレビューとマージのために、これらの機能ブランチからトランクに送信されます。

2. 環境ベースの機能フラグ:

   • 機能フラグは、環境全体での機能のアクティブ化を制御するために使用されます。
   • フラグは、環境固有の構成ファイル、または CI/CD パイプライン構成の一部として保存されます。
   • トランク ブランチでは、すべての機能フラグはデフォルトで OFF に設定されています。
   • 必要に応じて、特定の環境 (サンドボックス、ステージング、運用環境など) でフラグを オン に切り替えることができます。

---

Sprint の JIRA バージョン

---

環境導入の流れ

1. サンドボックスまたはステージング環境:

   • QA と統合テストの場合、チームはトランクから Sandbox/ というプレフィックスが付いたブランチ (例: Sandbox/xyz) を作成できます。
   • このブランチは、CI/CD パイプラインを使用して専用の サンドボックス または ステージング環境 にデプロイされます。
   • QA チームは新機能を検証でき、統合テストは互換性を確認できます。
   • この環境では、特定の機能をテストするために機能フラグが オン に切り替えられます。

2. 本番リリースの準備:

   • リリースの準備をするには、トランクから release/xyz ブランチを作成します。
   • release/xyz ブランチはリリース候補として機能し、最初はベータ テストのために 運用トラフィックの 5% にデプロイされます。
   • 実稼働環境でのテストを可能にするために、このブランチでは新機能の機能フラグが オン に切り替えられます。
   • Nginx または同様のロード バランサーは、このトラフィック分割を処理して、ユーザーのサブセットのみが変更を確認できるようにすることができます。

---

機能フラグ: 例と使用法

1. フラグ構造:

   • 機能フラグを構成ファイルに保存します (例: config/feature-flags.json)。

    {
      "feature_xyz": false,
      "feature_abc": true
    }
   

• 実行時に環境変数を使用してフラグを制御します:
  

   FEATURE_XYZ=true FEATURE_ABC=false npm start
  

1. バックエンドの例:

   • コード内のフラグを切り替えます:

    const featureFlags = require('./config/feature-flags');
   
    if (featureFlags.feature_xyz) {
        console.log('Feature XYZ is enabled!');
    } else {
        console.log('Feature XYZ is disabled.');
    }
   

2. フロントエンドの例:

   • フラグを使用して条件付きで UI コンポーネントをレンダリングします。

    if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
        render(<newfeaturecomponent></newfeaturecomponent>);
    } else {
        render(<oldfeaturecomponent></oldfeaturecomponent>);
    }
   

3. テスト中のフラグの切り替え:

   • テスト用のフラグを切り替えるには、構成変数または環境変数を更新し、関連するサービス (フロントエンドまたはバックエンド) を再起動します。

    FEATURE_XYZ=true npm start
   

• CI/CD パイプラインの場合は、デプロイ中に適切なフラグ値が環境に挿入されていることを確認してください。

---

本番環境でのテスト

1. ベータ テストのトラフィック ルーティング:

   • Nginx 構成を使用してトラフィック割り当てを制御します。

    http {
        upstream stable_backend {
            server stable_backend_1;
            server stable_backend_2;
        }
   
        upstream canary_backend {
            server canary_backend_1;
            server canary_backend_2;
        }
   
        upstream mixed_backend {
            server stable_backend_1 weight=45;
            server stable_backend_2 weight=45;
            server canary_backend_1 weight=5;
            server canary_backend_2 weight=5;
        }
   
        server {
            listen 80;
            server_name my-app.example.com;
   
            location / {
                if ($http_x_qa_test = "true") {
                    proxy_pass http://canary_backend;
                    break;
                }
   
                proxy_pass http://mixed_backend;
            }
        }
    }
   

• ロード バランサーの重みを調整して、運用トラフィックの 5% を新しいバージョンを実行しているサーバーにルーティングします。

1. 本番環境での専用の QA テスト:
   • QA チームは、リクエストにカスタム Cookie (例: qa-test=true) を添付できます。
   • Nginx はこの Cookie をチェックし、これらのリクエストを 100% の確率で新しいバージョンにルーティングし、実稼働環境での対象を絞ったテストを保証します。

---

リリースの安定化

1. 問題の修正:

   • 開発者は、PR をトランク ブランチに開くことで、ベータ テスト中に特定された問題を修正します。
   • マージされると、これらの修正は厳選して release/xyz ブランチに追加されます。

2. リリースを完了中:

   • すべての問題が解決され、ブランチが安定すると、リリース ブランチに セマンティック バージョン (例: v1.2.0) のタグが付けられ、安定したバックエンドへのデプロイがトリガーされます。
   • リリースノートはドキュメント用に生成され、関係者と共有されます。

---

ホットフィックスプロセス

1. ホットフィックス ブランチの作成:

   • 緊急の修正の場合は、最新の実稼働タグから直接 hotfix/xyz ブランチを作成します。
   • ホットフィックス ブランチは、リリース ブランチと同じ安定化およびタグ付けプロセスに従います。

2. バージョン管理:

   • ホットフィックスは、セマンティック バージョニング (SemVer) 標準に従って、パッチ バージョン を増加させます (例: v1.2.0 から v1.2.1)。

---

ブランチのクリーンアップ

• 混乱を避けるために、マージされたブランチを定期的に削除します。
• 組織を維持するために、未使用の機能フラグを定期的に削除します。
• GitHub Actions または同様のツールを使用して、マージ後のブランチ削除を自動化します。

---

代替の QA およびテスト戦略

本番環境で QA トラフィックをルーティングするための追加の戦略には、Cookie の代わりに次のようなものがあります。

1. ヘッダーベースのルーティング:

   • QA はカスタム ヘッダー (例: X-QA-Test: true) をリクエストに追加します。
   • Nginx は、テストのためにこれらのリクエストを新しいバージョンにルーティングします。

2. IP ベースのルーティング:

   • QA の IP アドレスに基づいて新しいバージョンへのトラフィックを制限します。

3. 認証トークンベースのルーティング:

   • QA は、リクエストが新しいバージョンにルーティングされることを保証するロールまたはトークンに関連付けられた特定のテスト アカウントを使用してログインします。

---

結論

このリリース プロセスでは、トランク ベースの開発と環境ベースの機能フラグを利用して、スケーラブルでテスト可能、本番環境でも安全な展開ワークフローを作成します。サンドボックス環境、トラフィック ルーティング、専用のテスト戦略を使用することで、チームはリスクを最小限に抑えながら高品質の機能を提供できます。このアプローチにより、問題を早期に発見して効率的に対処できるようになり、シームレスな機能のロールアウトとホットフィックスへの道が開かれます。

以上がWeb アプリケーションのリリース プロセスの合理化: 機能フラグを使用したトランクベースの開発の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。