Xcode のためのリモート Mac：ローカルビルド、リモートビルド、画面共有のどれを選ぶか

プロジェクトをネットワーク越しに共有しても Xcode は移動しない。アプリは手元の Mac で動き続け、サーバーにプロジェクトのデータを要求し続けるからだ。リモート Mac で Xcode を動かしてその画面を見るのは別の構成で、アプリとファイルが同じ場所に残り、回線は表示と入力だけを運ぶ。何かを設定する前にどちらを選ぶかを決めておけば、その後の混乱のほとんどは解消する。

よくあるケースは三つの構成で足りる。違いはワークスペースがどこにあり、どのマシンがコンパイルするかにある。続ける前に、この二点への答えを書き留めてほしい。

Xcode を動かすマシンに名前を付ける

第一の構成ではすべてがローカルだ。作業コピー、インデックス、ビルドのすべてが手元の Mac にあり、ネットワークはリポジトリと依存関係の通信だけを運ぶ。第二ではプロジェクトが Xcode とともにリモート Mac に残るので、インデックス作成とコンパイルはファイルのそばで行われ、回線は画面の内容とキー入力だけを運ぶ。第三では編集はローカルで行い、明示的なソースの受け渡しの後にリモートホストでビルドを走らせる。表はそれぞれが何を動かすのかを挙げている。

まず真ん中の列を読むとよい。障害がどこに出るかを決めるのはそこだからだ。ソースがリモートにある流れは回線が遅いときに失敗し、リモートのコンパイラを使う流れは受け渡しが曖昧なときに失敗する。両方の責任を負うのは第三の構成だけだ。

メガバイトではなく往復の回数を数える

エディタとインデクサは小さなファイル操作を大量に発行し、ファイルシステムがリモートだとその一つひとつが往復になる。だからマウントしたワークスペースは、大きなコピー一回とは違って遅延に敏感になる。ファイル転送の時間を測っても、その流れがどれほど快適かはほとんど分からないということだ。リモート表示は逆の性格で、連続した流れを運び、遅延よりも帯域に強い。二つを一つの数値で比べると、自信たっぷりの間違った答えが出る。

どちらの構成も本質的に速いわけではない。正しい選択は実際にやる作業で決まるので、次の一歩はベンチマークではなくその作業を試すことだ。

ソースの受け渡しを明示する

両方のマシンが作業コピーを持つときは、どちらが正であり、リモートビルドがどのリビジョンを使ったのかを決める。コミットは、一つのマウントした作業ツリーを二つの道具で編集するより明確な受け渡しだ。コミットには同一性があり、マウントにはないからだ。生成物とインデックスのデータにも持ち主が要る。ソースから作り直されるものであり、ソースであるかのように移動させるべきではない。衝突の規則がない双方向ミラーは仕事の流れではなく、競争だ。

リモートでビルドするには、リモートホストに正しいツールチェーンが入っていることと、非公開の依存関係のための認証情報が要る。ホストに到達できる VPN は、あなたのアカウントの権限を貸してはくれないし、そこに Xcode を入れてくれるわけでもない。

仕事の流れを決める前に経路を確かめる

リモートホストを前提に設計する前に、そのホストを検証し、そのあとで実際に流れが行う操作で回線を測る。下のコマンドはツールチェーン、有効な開発者ディレクトリ、リモートのワークスペースを苦しくするファイル監視のコストを確認する。最後の一つはローカルではなくネットワーク経路で実行してほしい。

xcode-select -p
xcodebuild -version
ssh mac-builder 'xcodebuild -version'
time git status --porcelain

完全な Xcode が入っていないホストは xcodebuild からエラーを返す。これはネットワークではなくツールチェーンの問題だ。開発者ディレクトリを見ればビルドがどの Xcode を使うか分かり、コマンドラインツールだけを指す経路ならアプリは入っていない。マウントした共有の上でリポジトリの状態コマンドの時間を測れば、往復のコストが直接見える。ローカルの実行と比べれば、意味のある数値が出る。その差がすでに不快なら、マウントしたワークスペースの流れは本物のエディタの下でもっと悪くなる。

どの構成を選んだか、どのマシンがソースを持つか、受け渡しがどう働くかを記録しておく。そのメモがあれば、次の受け入れやノート PC の交換は調査ではなく設定の作業になる。