ずれる前にSDKを追いつかせる

プロジェクトの初期に構築されたパリティは、出荷後に後付けされるパリティよりも1000分の1のコストで済む。RakuAIのバインディングはランタイムと共同開発され、すべてのPRでゲートされている - だからどちらのバインディングを選んでも、後で機能から締め出されることは決してない。

以前にも複数リポジトリのプロジェクトを潰してきたのを見てきた、ある特定の失敗モードをすでに警戒していた。それが土曜の朝のスタート地点だった。ランタイムはある週末に機能を追加し、SDKは翌月までそれに追いつかない。片方のバインディングのサンプルは動き、もう片方のバインディングのサンプルは静かに退行する。バージョン番号が一致しなくなる。それぞれのリポジトリのCIはグリーンなのに、両者の間の統合は壊れている。

その映画は2年目のリプラットフォームで終わる。私はRakuをそういうやり方では作らない。この週末の計画は、ギャップが形成される前にSDKをランタイムに追いつかせ、ギャップが二度と形成されないだけの十分なインフラを残しておくことだった。

SDK側で着地したもの

SDKにとって大きな週末だった。ランタイム側は静かなものだった(その大きな一押しのほとんどは前の週末に起きており、PR #104がVIO/SLAM、QoSスケジューラ、パフォーマンスハーネス、テレメトリパイプラインを着地させていた)。今回はバインディングにとってのキャッチアップの週末だった。

主なハイライトはこうだ。

• SDK v0.2.0、UnityとUnrealのパリティ、包括的な検証付き
• 両バインディングにおけるHelloARサンプル、明示的なフェイルオーバーのデモ付き
• 複数オブジェクト対応とインタラクティブなチュートリアルを備えた、強化されたUnityサンプルのインタラクション
• 包括的な利用例を備えた、強化されたUnreal APIドキュメント
• SDKリポジトリへ移植されたAgent-Queue Seederワークフロー
• セマンティックバージョニングとリリース自動化を備えた、SDK v0.2パッケージ公開用のCI/CDパイプライン
• リポジトリのホームページとWiki統合を備えた、SDK v0.2ドキュメントとクイックスタート
• Epic #42：SDK・ランタイムパリティテストインフラの完成

Epic #42の作業が今回の目玉だ。これは、両方のバインディングを同じ正規のシナリオに対して動かし、それらが同じように振る舞うことを確認するテストスイートだ。Unity HelloARとUnreal HelloARは、それぞれモデルを読み込み、それをマーカーにアンカーし、描画し、テレメトリを報告する。パリティテストは、2つのバインディングが報告するテレメトリが許容範囲内であること、そして同じモデルが両方で正しく読み込まれることを確認する。もしランタイムの変更が片方のバインディングだけを壊し、もう片方は壊さなかった場合、パリティテストがそれを捕捉する。

なぜこの段階でパリティテストが重要なのか

Rakuのsdkはまだ出荷されていない。公開リリースはない。チーム外の誰かがこれに対してコードを書くまでには、まだ数か月ある。ではなぜ今パリティを気にするのか。

なぜなら、プロジェクトの初期に構築されたパリティテストは、すでに出荷されたプロジェクトに後付けされるパリティテストよりも1000分の1のコストで済むからだ。ランタイムが追加する新しいC APIはすべて、初日から両方のバインディングを通して動かされる。公開インターフェースに触れるすべてのPRは、パリティテストが引き続き通ることを示すか、通らない理由を説明しなければならない。コストはPRあたり数分だ。節約できるのは、Unrealでしか再現しない問題をパートナーが報告してきて、チームがその理由を突き止めなければならなくなる、といった後々の何か月ものトリアージだ。

もう一つの理由は、パリティテストがアーキテクチャ上の問題を表面化させることだ。ある機能がUnityでは公開しやすくUnrealでは難しいとき、問題はたいていバインディング側にはない。ランタイムのC API側にある。その非対称性はシグナルだ。この週末、パリティテストはそうした非対称性を2件表面化させ、どちらのケースでも修正は片方のバインディングでその非対称性を回避することではなく、ランタイムのAPI表面を変更することだった。

2ストリームのワークフローの仕組み

エージェントを使った複数リポジトリ開発について、私が行き着いたパターンはこうだ。

リポジトリごとに1つのエージェントキュー。 ランタイムには自分専用のイシューキューがあり、SDKには自分専用のイシューキューがあり、ドキュメントにも自分専用のものがある。各エージェントは自分のリポジトリの中で作業する。単一のエージェントが1つのPRで2つのリポジトリの間の継ぎ目にまたがろうとすることはない。

リポジトリをまたぐ調整はイシューレベルで行う。 ある機能が両方のリポジトリでの変更を必要とするとき、相互参照を伴った2つの連動するイシューが同時にファイルされる。ランタイムのPRが先に着地する。SDKのPRは、ランタイムのPRがマージされるまで保留される。それからSDKのPRは新しいランタイムビルドに対して更新され、再テストされ、数時間以内にマージされる。

各バインディングにおける正規のサンプルセット。 Unity HelloARとUnreal HelloARが正規のテスト用媒体だ。C APIのあらゆる変更は両方で動かさなければならない。サンプルは後付けのおまけではない。公開インターフェースの一部だ。

CIゲートとしてのパリティテスト。 この週末にEpic #42として着地したパリティテストインフラは、今やどちらかのリポジトリに触れるすべてのPRで実行される。ランタイムの変更が両方のバインディングを動かしていない場合、パリティテストが変更が両側で機能することを示すまで、そのPRはマージをブロックされる。

これがビルダーにとって何を可能にするか

もしあなたが、いずれRakuの上に何かを構築することを考えているUnity開発者なら、このバインディングはランタイムを追いかけているのではなく、ランタイムと共同開発されている。UnityのAPIは遅れをとらない。サンプルは今日動くし、バージョン1.0でも動く。

もしあなたがUnreal開発者なら、同じことが当てはまる。UnrealバインディングはUnityバインディングと全く同じ優先度を持つ。パリティテストがそれを証明している。

もしあなたがどちらのバインディングから始めるか決めかねているなら、答えはあなたのチームの既存のスキルに合うほうだ。パリティテストがあるからこそ、バインディングの選択が後で機能から締め出されることはない、と約束できる。

もしあなたが、このエンジンが自社のスタックにどう統合されるかを考えているパートナーなら、表面はC APIに加えてUnityバインディング、Unrealバインディング、そしていずれさらに数個(Godotがロードマップにあり、Webネイティブもロードマップにある)になるだろう。新しいバインディングはそれぞれ、出荷前に正規のセットに対する自分自身のパリティテストを着地させなければならない。この規律は組み込み済みだ。

まだ粗いところについて正直に

パリティテストは基本をカバーしている。マーカーベースのアンカリングは両方のバインディングで動く。HelloARは両方で読み込みと描画ができる。テレメトリは両方で正しく報告される。より難しいパリティの問題、フルのハンドトラッキング、音声パイプライン、マルチプレイヤーのポーズ同期、それらはランタイム側がまだ完成していないため、まだパリティテストされていない。それらが完成すれば、同じゲートの下に入ってくる。

SDK v0.2公開用のCIパイプラインは立ち上がっているが、実際に公開されるパッケージは、それに対して統合することを勧められるほど安定してはいない。10月中はSDKを開発中のものとして扱ってほしい。11月までにはパリティテストが十分深くなり、推奨は違うものになるだろう。

この週末から覚えておきたいこと

2つある。

複数リポジトリのパリティは機能ではなく規律だ。 SDKがランタイムに追いついたこの週末は、ランタイムに何も光り輝く新機能がなかった週末だ。デモできることは何も起きなかった。起きたのは、SDKがもう遅れをとらなくなったということだけだ。それは、放置すれば複数リポジトリのプロジェクトを潰す種類の作業だ。次に大きなランタイムの機能が着地したときに忘れないよう、これを書き留めておきたい。

エージェントキューはリポジトリ単位でスケールする。 同じワークフローの中で両方のリポジトリにまたがる1つのキューを走らせると、先週末にランタイムレベルで説明したマージコンフリクトの散らかりの初期版が生じた。キューをリポジトリごとに分離すると、そのほとんどが解消された。問題空間が適切に切り分けられていれば、エージェントは互いに足を引っ張り合わなくなる。

土曜の夜、SDKとランタイムはパリティが取れている。大きな週末だった。正しい種類の週末だった。