実際の開発フローに対応

専有クラウドMacをビルド、テスト、リモート運用に組み込む

HexVMは注文ごとに独立したMac mini物理ノードを割り当てます。仮想マシンではありません。既存のコードリポジトリ、スクリプト、リリースルールを維持したまま、macOSとApple Siliconが必要な工程だけをクラウドへ移行できます。

pipeline / macos-arm64 実行中
01

コードリポジトリ

コミットでトリガー
02

専有ノード

環境チェック
03

Xcode

ビルド・テスト
04

成果物

アーカイブ・アップロード
実行結果 再現可能な環境、追跡可能なタスク
ワークロードで選ぶ

クラウドMacへ移行するタスクを見極める

すべての工程を移行する必要はありません。用途を選び、推奨フロー、準備する入力、リリース前の確認項目を確認してから、ノード数と実行方法を決めます。

継続的インテグレーションに最適

macOS Runnerを制御可能な固定実行環境にする

コードコミット後、リポジトリプラットフォームがself-hosted runnerを割り当て、専有ノードで依存関係の復元、テスト、アーカイブ、成果物のアップロードを実行します。トリガールール、同時実行ポリシー、鍵の権限はチームが定義します。

iOS CI/CDの流れを見る
入力リポジトリ、ビルドスクリプト、証明書素材
実行xcodebuildによるテストとアーカイブ
確認ログ、テスト結果、インストール可能な成果物
iOS CI/CD

コードコミットから成果物アップロードまでの5段階

専有物理マシンは、固定Xcodeバージョン、安定したキャッシュディレクトリ、明確な権限境界が必要なパイプラインに適しています。ノードは他の注文と計算リソースを共有しませんが、リポジトリ権限、署名素材、タスクのクリーンアップはチームが管理します。

  1. 01

    コードコミット

    ブランチ、タグ、マージリクエストでタスクを起動します。まずリポジトリ側でリリースフローを起動できるメンバーを制限し、通常のテストタスクに署名権限を与えないようにします。

    確認:トリガールールを再現できる
  2. 02

    Runnerの割り当て

    self-hosted runnerに、チップアーキテクチャ、Xcodeのメジャーバージョン、用途などの明確なラベルを設定します。単一ノードの同時実行数は、タスクのメモリピークとディスク書き込み量に基づいて評価します。

    確認:タスクが対象ノードだけで実行される
  3. 03

    ビルド・テスト

    依存関係のバージョンを固定し、ユニットテスト、UIテスト、静的チェックを実行します。失敗時は終了コード、テストレポート、重要なログを保存し、最後の画面出力だけに頼らないようにします。

    確認:失敗原因を特定できる
  4. 04

    署名・アーカイブ

    リリースタスクに必要なキーチェーンを一時的にロック解除し、完了後すぐにアクセスを閉じます。証明書とプロビジョニングプロファイルはプロジェクトと環境ごとに分け、通常のビルドディレクトリに平文で長期保存しません。

    確認:権限範囲が最小限である
  5. 05

    成果物のアップロード

    アーカイブ、テストレポート、シンボルファイルをアップロードし、コミットハッシュ、ビルド番号、ツールチェーンのバージョンを記録します。成功後は派生データからプロジェクトの機密情報を削除します。

    確認:成果物を追跡できる
テストとリリースは異なる権限レベルに分けることをおすすめします。

テストRunnerがリリース証明書に触れる必要はありません。保護されたブランチのアーカイブタスクだけが署名素材を読み込むようにします。これにより、通常のタスクスクリプトにエラーがあっても認証情報の露出範囲を広げずに済みます。

macOSアプリビルド

複数ブランチでルールを共有し、汚れた環境は共有しない

継続稼働するノードには検証済みのツールチェーンとダウンロードキャッシュを保持できますが、各タスクは独立した作業ディレクトリを使用してください。キャッシュは高速化のためのもので、ビルド成功の前提にしてはいけません。

ブランチ分離

タスク番号ごとに作業ディレクトリを作成し、ビルド終了後に一時ファイルを回収します。並行する2つのブランチで同じ依存関係ディレクトリや出力パスを書き換えないようにします。

  • デフォルトブランチのリリース権限を固定
  • 一時ブランチにクリーンアップ期限を設定
  • コミットハッシュとビルドパラメータを記録

依存関係キャッシュ

キャッシュキーには少なくとも依存関係ロックファイルの要約、ツールチェーンのメジャーバージョン、アーキテクチャを含めます。キャッシュヒットに異常がある場合は、ワンクリックでキャッシュを迂回してクリーンビルドを実行できるようにします。

  • ダウンロードキャッシュとビルド成果物を分離
  • 容量しきい値と回収順序を設定
  • 定期的にキャッシュなしの基準タスクを実行

リリース成果物

テスト結果、公証準備素材、インストーラ、シンボルファイルを分けて保存します。成果物名にはバージョン、ビルド番号、コミット識別子を含めます。

  • ビルド後に整合性を検証
  • リリースディレクトリへの書き込みメンバーを制限
  • 生成に使用したツールチェーンのバージョン記録を保持
build-check.sh
xcodebuild -version
xcode-select -p
swift --version
git rev-parse --short HEAD
xcodebuild test -scheme "Project" -destination "platform=macOS"

毎回のビルドログの冒頭でバージョンを確認します。環境のずれが見つかったら、まずツールチェーンのパス、プロジェクトのコミット、依存関係ロックファイルを比較し、その後キャッシュを削除するか判断します。

AIモデル実験

Apple Siliconで推論の互換性と継続タスクを検証

クラウドMacは、実験環境の再現、ツールチェーンの互換性確認、復旧可能なバッチ処理タスクの実行に適しています。ハードウェア性能は2つの販売中構成を上限とし、記載のない仕様へ実験結果を外挿しません。

入力基準を固定

モデルバージョン、サンプル要約、乱数シード、実行パラメータを保存します。出力比較には同じ入力セットを使い、1回の実行だけで完全な検証と判断しないでください。

環境バージョンを記録

ランタイム、依存パッケージ、モデル変換ツールのバージョンを固定します。アップグレード前に環境を複製して回帰サンプルを実行し、出力とリソース使用量の変化を確認します。

復旧ポイントを設計

継続タスクはバッチ単位で進捗と結果を書き込み、プロセス終了後は確認済みのバッチから再開します。永続化されていないメモリ状態を唯一の進捗情報にしないでください。

リソースの境界を監視

メモリピーク、ディスク増加量、タスク所要時間、失敗サンプルを記録します。機種のリソース上限に達したら、まずバッチサイズまたはキュー方式を調整します。

ローカル環境からスムーズに移行

3段階の移行パス:データ、ツールチェーン、CI接続

まず複製し、次に検証し、最後に切り替えます。クラウドノードがビルド、権限、成果物の確認を連続して通過するまで、ローカルの復旧経路を残します。

01

ステップ1

必要なデータを移行

コードリポジトリ、成果物ストレージ、暗号化転送を優先してプロジェクトデータを複製します。キャッシュ、一時ビルドディレクトリ、過去のログ、使用していない認証情報は除外します。

確認項目

  • リポジトリのブランチとサブモジュールが完全
  • 大容量ファイルの要約がローカルと一致
  • 機密設定がリポジトリに書き込まれていない
  • 旧ノードへ戻せる
02

ステップ2

ツールチェーンを再現

ローカルのXcodeバージョン、コマンドラインツールのパス、パッケージマネージャーのロックファイル、環境変数の出所、ビルドスクリプトの入口を記録し、クラウド上で順に再現します。

確認項目

  • ツールのバージョンとパスを記録済み
  • クリーン環境で依存関係を復元できる
  • テスト結果が基準値を満たす
  • キャッシュ削除後もビルドできる
03

ステップ3

CIスケジューリングに接続

まずリリース対象外のブランチを接続し、割り当てラベル、タイムアウト、ログ、クリーンアップルールを確認してから、保護されたブランチと署名・アーカイブタスクを開放します。

確認項目

  • Runnerラベルに曖昧さがない
  • 失敗したタスクを自動回収できる
  • リリース権限が承認済みフローに限定されている
  • 成果物とログを追跡できる
切り替え条件

クリーンビルド、失敗からの復旧、権限検証、成果物の追跡を各1回以上完了してから、クラウドノードを主要な実行環境に設定します。

証明書とアプリ公開フロー

機密性の高い権限を必要な工程だけに限定

HexVMは専有物理ノードとリモートアクセス機能を提供します。証明書の申請、プロビジョニングプロファイルの管理、キーチェーン権限、公開承認、最終提出はすべてお客様のチームが管理します。

工程 チームの担当 ノードの実行 確認記録
証明書の準備

証明書の用途を決め、エクスポート用パスワードを管理し、アクセス可能なメンバーを制限します。

管理されたセッションで必要な素材をインポートし、キーチェーンを常時開放しません。

証明書名、有効状態、承認済みメンバー。

プロビジョニングプロファイル

アプリ識別子とリリース環境ごとにファイルを管理し、無効なバージョンを削除します。

ビルド前に対応関係を検証し、失敗時はアーカイブを停止します。

アプリ識別子、チーム情報、ファイルバージョン。

署名・アーカイブ

保護されたブランチとリリースタスクを承認し、ビルドパラメータを管理します。

アーカイブ、エクスポート、整合性チェックを実行し、明確な終了コードを出力します。

コミットハッシュ、ビルド番号、アーカイブ要約。

アプリの提出

バージョン情報、プライバシー関連素材、スクリーンショット、公開範囲を確認します。

検証済みの成果物とアップロード用ツール環境を準備します。

提出者、成果物バージョン、提出結果。

キーチェーン権限

署名工程でのみロックを解除し、タスク終了後すぐに閉じます。プロジェクトや環境ごとに独立したアクセス方針を使い、テストタスクがリリース権限を継承しないようにします。

アーカイブ検証

アプリ識別子、署名ID、バージョン番号、ビルド番号、エクスポート結果を確認します。想定と異なる項目があればアップロードを停止し、手作業でエラーを無視して続行しません。

ノード解放前

Runnerの登録を解除し、証明書とプロビジョニングプロファイルを削除します。リポジトリ認証情報、ビルドディレクトリ、ログ内の機密項目を消去し、必要な成果物が転送済みであることを確認します。

導入前チェック

チーム導入チェックリスト

以下6項目すべてに明確な担当者と確認記録を設定します。口頭の取り決めに依存する項目が残っていると、ビルド失敗、メンバー変更、ノード解放時にリスクが生じます。

01

リージョン選択

開発者の所在地、リポジトリのデータ経路、成果物のアップロード先を基準にリージョンを選びます。現在販売中のリージョンはシンガポール、日本(東京)、韓国(ソウル)、香港、米国東部、米国西部の計6リージョンです。

  • テストチームからノードへの接続品質
  • 主要なデータ転送方向を記録
  • リージョンがチーム内の要件を満たすことを確認
02

機種選択

実際のプロジェクトで完全なビルドを実行し、メモリピーク、ディスク増加量、同時実行方式に基づいてHexVM M4またはHexVM M4 Proを選びます。

  • クリーンビルドの所要時間を記録
  • 依存関係と成果物の使用容量を確認
  • 単一の増分ビルドだけで容量を判断しない
03

アカウント権限

ノード管理、日常開発、CI実行、リリース権限を分けます。メンバーの離脱や役割変更時には、鍵とリポジトリの承認を直ちに回収します。

  • 承認済みメンバー一覧を作成
  • テスト権限とリリース権限を分離
  • 認証情報のローテーション手順を策定
04

リポジトリ接続

範囲を制限したデプロイ認証情報またはRunner承認を使い、タスクに必要なリポジトリだけを開放します。スクリプトでトークン、秘密鍵、完全な認証情報をログに書き込まないでください。

  • リポジトリとブランチの範囲を制限
  • 機密出力をマスキング
  • 認証情報を取り消した後の動作を検証
05

監視と復旧

タスクキュー、成功率、失敗原因、ディスク使用量、実行時間を記録します。継続タスクには復旧ポイントを保存し、ビルド失敗後に安全に再試行できるようにします。

  • 失敗アラートの受信者を定義
  • ディスク容量のしきい値を設定
  • 復旧手順を定期的に検証
06

コストの振り返り

ノードごとに実効ビルド時間、待機時間、アイドル時間、キャッシュ効果を集計します。短期タスクは日単位または週単位で、継続パイプラインは月単位と四半期単位で比較できます。

  • 実行時間と待機時間を区別
  • 失敗時の再試行による消費を振り返る
  • プロジェクトごとにノード利用記録を割り当てる
まず基準タスクを実行してから、長期構成を決めます。

実際のリポジトリでクリーンビルド、増分ビルド、テスト、アーカイブ、成果物アップロードを実行します。サポートに原因調査を依頼する場合は、ノードID、リージョン、発生時刻、再現手順、機密情報を除いたログを用意してください。

デプロイを開始

既存のパイプラインに合う専有Macを選ぶ

販売中の2機種と利用期間を比較し、リージョンと追加オプションを設定すれば注文できます。料金はすべて米ドル(USD)で決済され、実際の利用可否はコンソールのリアルタイム表示に基づきます。