【ITニュース解説】Mobile Frontend Preview with Signadot Sandboxes

現代のソフトウェア開発、特にモバイルアプリケーションとそれに連携するバックエンドシステムを扱う現場では、共有テスト環境がしばしば課題となる。複数の開発者が同じ環境を使うことで、一人の開発者が加えた変更が他の開発者のテストを妨げたり、環境全体が不安定になったりする事態が頻繁に発生する。このような問題を解消し、開発者が独立した環境で安全かつ効率的に作業を進めるための強力なソリューションが「Signadot Sandboxes」である。

Signadot Sandboxesは、既存のバックエンドシステムの中から特定のサービスだけを切り離し、開発者が独自の変更を加えたバージョンでテストできる、仮想的な独立環境を提供する。これは、まるで本番環境の必要な部分だけを複製し、自分だけの実験室を持つようなものだ。この仕組みにより、モバイルアプリ開発者は、まだ本番環境にデプロイされていないバックエンドの新しい機能や修正を、他の開発者に影響を与えることなく、自分の手元のアプリから直接検証できるようになる。

この技術を利用するには、いくつかの前提条件がある。基本的にはmacOS環境で、コンテナ化されたアプリケーションを管理するKubernetesクラスターが動作していること、そしてiOSアプリ開発のためにXcodeがインストールされていることが求められる。また、KubernetesやiOSアプリ開発の基本的な知識があると、よりスムーズに理解し、作業を進められるだろう。

まず、Signadotを利用するための基盤となるインフラをセットアップする。開発者は「Signadot CLI」というコマンドラインツールをインストールする。これは、開発者のローカルPCとSignadotのクラウドプラットフォームを連携させ、サンドボックスの管理やトラフィックのルーティング設定を行うための主要なインターフェースとなる。

次に、「HotROD」というマイクロサービスアプリケーションをKubernetesクラスター上にデプロイする。HotRODは、配車サービスを模したデモアプリケーションで、「フロントエンド」「ドライバー」「ロケーション」「ルート」といった複数の独立したサービスが連携して動作する。これらのサービスが正しくデプロイされ、Kubernetes上で期待通りに動作していることを確認する。

さらに、Kubernetesクラスター内に「Signadot Operator」をインストールし、設定する。このOperatorは、クラスター内でサンドボックスの生成や管理、トラフィックのルーティングルールの適用、クラウドへの安全な接続といったSignadotの主要な機能を自動的に制御する役割を担う。これにより、開発者は手動での複雑な設定をすることなく、サンドボックスを効率的に運用できる。

インフラが整ったら、サンドボックスの作成とテストに移る。サンドボックスの核心は「フォーク（fork）」という概念にある。これは、既存のサービス（例えばHotRODの「ルートサービス」や「ドライバーサービス」）を丸ごと複製し、その複製に対して独自の変更を適用した新しいバージョンを動作させることだ。この新しいバージョンは、他のサービスや本番環境のサービスとは完全に分離されているため、安心してテストできる。

具体的なテスト例として、HotRODアプリケーションの2つの新機能を試す。一つは、配車時の到着予定時刻（ETA）を「分」単位から「秒」単位に変更する「高速ETA計算機能」だ。もう一つは、ドライバーのナンバープレートに「SD-」という接頭辞を追加する「ドライバーライセンス形式変更機能」である。これらの機能は、それぞれHotRODの「ルートサービス」と「ドライバーサービス」に対する変更として実装されている。

開発者は、これらの新機能が実装されたHotRODのソースコードを取得し、それぞれのサービス用のDockerイメージをビルドして、Dockerレジストリにプッシュする。Dockerイメージは、アプリケーションとその実行に必要なすべてのものをパッケージ化したもので、コンテナ技術の基盤となる。

次に、これらの新しいイメージを使ってサンドボックスを構成するためのYAMLファイルをSignadotに用意する。これらの設定ファイルには、どのサービス（例えばHotRODのルートサービス）をフォークし、そのフォークしたサービスにどの新しいDockerイメージ（例えば「ETAを秒で計算するルートサービス」のイメージ）を使うかを記述する。一つのサンドボックスで複数のサービスをフォークし、組み合わせてテストすることも可能だ。例えば、「ETA秒計算」と「SD-ライセンスプレート」の両方を同時に試すための「combined-features」サンドボックスを作成できる。

これらのYAML設定ファイルをSignadot CLIを使ってデプロイすると、Signadotは指定されたサービスをフォークし、新しいイメージでサンドボックス環境を構築する。サンドボックスが正常に構築され、「Ready」状態になったことを確認すれば、テストの準備は完了する。

ローカル環境でサンドボックスに接続するためには、signadot local connectコマンドを使用する。このコマンドは、開発者のPCとKubernetesクラスター内のSignadotサンドボックスとの間に安全なトンネルを確立し、モバイルアプリからのリクエストが正しくサンドボックスにルーティングされるようにする「DevMeshトラフィックルーティング」を有効にする。

最後に、モバイルアプリとの連携とテストを行う。HotROD iOSアプリは、開発者モードを備えており、ユーザーが「本番環境（ベースライン）」と様々な「サンドボックス環境」を簡単に切り替えられるようになっている。この切り替えは、アプリがバックエンドにAPIリクエストを送る際に、「routingHeaders」というHTTPヘッダーに特別な「sd-routing-key」を含めることで実現される。このキーがSignadotのルーターに、どのサンドボックスにリクエストを振り分けるべきかを指示するのだ。

具体的なテストシナリオとしては、まず「ETAを秒で表示する機能」だけが有効なサンドボックスに接続し、iOSアプリで配車をシミュレーションする。このとき、到着予定時刻が「2500秒」のように秒単位で表示されることを確認するが、ナンバープレートには「SD-」の接頭辞がないことを確認する。これは、ルートサービスだけが変更され、ドライバーサービスは影響を受けていないことを証明する。

次に、「SD-ライセンスプレート」機能と「ETA秒表示機能」の両方が有効な「combined-features」サンドボックスに接続してテストする。この場合、到着予定時刻が秒単位で表示されることに加えて、ナンバープレートにも「SD-T712345C」のように「SD-」の接頭辞が付与されていることを確認する。これにより、複数のサービスに対する変更が組み合わされたサンドボックスでも、期待通りに動作することが検証できる。

この一連のプロセスを通じて、Signadot Sandboxesを利用することで、開発者は本番環境に影響を与えることなく、独立した環境で新しい機能を安全にテストし、検証できることがわかる。これは、並行開発を促進し、実モバイルアプリでのバックエンド変更のリアルタイム検証を可能にし、包括的なテストのためのシームレスな環境切り替えを実現する、現代のソフトウェア開発において非常に価値のあるアプローチである。