M4 クラウドノードでのコンパイルとパッケージング：パイプラインを移行しました

VPSSparkの主力モデルはMac mini M4です。Xcodeの実行に加え、DockerやスクリプトもたまにつかうプロジェクトにとってCPUとメモリの違いは「コンパイル待ち」か「コードを書き続けるか」に直結します。旧プロジェクトのフルビルドをM4ノードへ移行したところ、クリーンコンパイル時間が約半分に短縮されました——節約できるのは時間だけでなく、中断されたフローも。リモートデスクトップでは特にそれが際立ちます。

クラウドMacが向いているビルドシナリオは？

移行前に、代表的なシナリオを痛みの度合いで整理しました：

「コンパイルできる」から「本開発をクラウドに移せる」へ

クラウドMacをリモートディスプレイ代わりに使うのはもうやめました。クリーンビルドが大幅に短縮されると、ユニットテスト・静的解析・成果物の署名検証まで同じ固定環境で回せるようになり、「自分のマシンでは通るのに同僚の環境で通らない」というやりとりが減ります。

Apple Siliconでは、リンカーとSwiftコンパイラがメモリ帯域幅により敏感です。Swift Package、混在モジュール、大型Asset Catalogが多いプロジェクトでは、コンパイルピーク時にスワップへ逃げないよう、ローカルの余裕よりやや大きめのRAMをクラウドで確保することをおすすめします。内部では同じプロジェクトを異なるノードで繰り返し計測し、wall timeと尾端遅延の中央値を比較しています。

キャッシュ三種：DerivedData · CocoaPods · SPM

キャッシュはビルド速度に最も直接的に効くレバーです。以下の三つのディレクトリはイメージのベースラインに書き込み、バージョンタグを付けることをおすすめします：

~/Library/Developer/Xcode/DerivedData/   # Xcode インクリメンタルコンパイルキャッシュ
~/Library/Caches/CocoaPods/              # CocoaPods ダウンロードキャッシュ
~/.spm-cache/ (or ~/.swiftpm/)           # Swift Package Manager キャッシュ

# 日常のイテレーション：このセッションに必要な差分のみ同期
# 真のコールドスタートはイメージの大規模アップグレード時にまとめて

日常のイテレーションでは本セッションに必要な差分のみ同期し、真のコールドスタートはイメージの大版アップグレード時にまとめて処理することで、速度を保ちつつエグレス帯域を節約できます。

観測・ロールバックと「深夜に電話に出られる人」

クラウドビルドはwall time削減だけでなく、障害時の迅速な特定にもかかわります。典型的なインシデントを四分類し、それぞれ独立したアラート閾値とオンコールRunbookを用意しています：

• イメージドリフト — XcodeバージョンまたはCLTがサイレントに更新
• 依存解決タイムアウト — SPM / CocoaPodsのフェッチタイムアウト
• 署名証明書の期限切れ — 配布証明書またはProvisioning Profileの期限切れ
• Gitリモート到達不能 — サブモジュールのDNS遅延がビルド遅延として誤認

チームが複数のタイムゾーンにまたがる場合は、「最後に成功した夜間ビルドの成果物ハッシュ」と「失敗ログの抜粋」を読み取り専用チャネルに自動投稿することで、朝の引き継ぎを軽くできます。誰かが不在でも、環境問題かコード回帰かを判断できる人が残ります。

ロールバックはディスク全体のクローンだけが手ではありません——多くのチームにとって、「直前まで動いていたXcode + CLT + CocoaPodsの組み合わせ」を収めた軽量イメージの方が、ユーザーホーム全体を復元するより速く復旧できます。コンソール側でビルド履歴に紐づいたイメージタグを提案する機能を順次導入していく予定です。

さらに、夜間パイプラインでサブモジュールのフェッチ時間を別途計測することをおすすめします：サブモジュールのDNS解決が遅いと、コンパイルが遅いように見えることがあります。DNS・Gitハンドシェイクをコンパイルフェーズから分離すると、イメージ内のresolver設定を変えるべきか、サブモジュールを内部にミラーすべきかを判断しやすくなります。この傾向値をM4ノードのCPU使用率と並べて見ると、増設すべきかネットワークを修正すべきかも見えてきます。