Buildkite企業iOS CIは、Buildkiteでパイプラインを編成し、Xcodeに依存するビルドやテストをMac Agentで実行する構成にします。Linuxで処理できる工程は分けて運用し、キューへの振り分けを主機の隔離と取り違えないことが前提です。
対象となるのは、既存のiOSパイプラインをBuildkiteへ移行するプラットフォームエンジニアです。
macOSビルドノードのアカウント、起動、保守を管理するIT担当者も対象です。
リリースやセキュリティを担当し、テストと本番署名の境界を決める責任者にも役立ちます。
[ SECTION_01 ] 立案：Macで実行する工程を切り分ける
Buildkiteはジョブを編成してAgentへ処理を割り当てます。Appleのツールチェーンを使う処理はMacに送り、依存関係のない静的解析や汎用スクリプトは、実行環境の要件を確かめたうえで別のノードに残します。Buildkite Agentの仕組みとタスクルーティングを確認し、各工程の依存関係を先に整理します。
工程ごとに、必要な環境、資格情報、生成物を記録します。たとえば、ソース検査はOSに依存しなくても、シミュレーターを用いるテストやアーカイブはXcodeを使うため、Mac側で実行する判断が必要です。すべてをMacへ移すのではなく、実際のコマンドと依存ツールを基準にします。
構成の比較は、適合度を「高・中・低」で評価します。これは処理速度や安全性を保証する点数ではなく、工程の要件を見落とさないための設計評価です。
- MacでiOSビルドとシミュレーター試験を実行：適合度・高。 Xcodeを必要とする工程をmacOS上で実行できます。
- Linuxで共通チェックを実行：適合度・高。 Apple固有のツールに依存しない工程を分け、Mac側の役割を限定できます。
- 署名付きリリースと通常テストを同じ権限・主機で実行：適合度・低。 資格情報へのアクセスを分けられず、信頼境界を説明しにくくなります。
- キュー名だけで主機の隔離を判断：適合度・低。 キューはルーティングの設定であり、それだけでは主機や秘密情報の隔離を証明しません。
この段階で、各工程を「Mac必須」「別環境で実行可能」「署名など特別な認証が必要」に分けます。分類できない工程は、そのまま移行せず、使用コマンドと必要な入力を確認します。
[ SECTION_02 ] 準備：主機、アカウント、資格情報を整理する
Mac Agentの導入前に、主機のmacOS、CPUアーキテクチャ、利用可能なXcodeを記録します。開発用とCI用でXcodeが異なると、手元では成功する処理がAgent上で失敗することがあります。更新の担当者、変更前の検証方法、問題発生時の戻し方も決めておきます。
次に、AgentプロセスがどのmacOSユーザーで動くかを確認します。作業ディレクトリへの読み書き、リポジトリの取得、成果物の保管、キーチェーンへのアクセスを、実際のジョブと同じ実行ユーザーで検証してください。対話ログイン時に使える設定が、バックグラウンドのAgentにも使えるとは限りません。
資格情報は役割ごとに管理します。Agent Token、リポジトリ取得用の認証情報、署名に使う秘密情報を、ひとつの設定ファイルやジョブログへまとめないでください。BuildkiteのAgent Tokenに関する説明を参照し、発行、保存、失効の担当と取り扱いをチーム内で決めます。
[ SECTION_03 ] 導入：Agentを起動し、再起動後まで確認する
macOS向けのインストール方法と設定項目は、導入時点のBuildkite公式インストール手順に従います。Agentのバージョンやセットアップ方法によって細部が変わる可能性があるため、古い手順をコピーして済ませず、現行文書にある必要条件と起動方法を確認します。
起動後は、AgentがBuildkiteに接続したかだけでなく、登録されたキュー、実行ユーザー、ログの保存先を照合します。ログにはTokenやリポジトリ認証情報が出力されないようにし、ジョブの失敗時にも秘密情報が露出しないことを確認します。
手動起動と、ログイン後にlaunchdなどで管理する運用は区別してください。ターミナルから起動したAgentは、端末を閉じたときに停止する構成になっていることがあります。サービスとして管理する場合は、遠隔からの再起動後にAgentが接続し、対象キューのジョブを実行できるところまで検証します。プロセスが存在するだけでは、復旧確認として不十分です。
[ SECTION_04 ] ルーティング：キューとパイプラインを対応させる
Buildkiteのキュー管理文書を確認し、Agent側の登録先とパイプライン側の指定を一致させます。Buildkite Mac Agentという名前のキューを作っただけでは、そこに適切な主機が接続していることや、必要なXcodeが導入されていることまでは分かりません。
パイプラインでは、OSに依存しない工程と、Xcodeを必要とする工程を分割します。macOSビルドノードを指定したジョブでは、開始後のログで実際に処理を受けたAgentとホストを確認してください。キュー名だけを根拠に、macOSの版、ツールチェーン、隔離状態まで推測しないことが重要です。
Appleのコマンドラインツール設定に沿って、Agentの実行環境で選択されているXcodeを確認します。ジョブ内でxcode-select -pとxcodebuild -versionの結果を記録すれば、選択先とXcodeのバージョンをログで照合できます。開発者端末での確認結果を、Agentの実行環境の証拠として流用しないでください。
条件分岐で選ぶ実行先
以下をジョブ単位で確認し、該当する分岐に従って実行先を決めます。条件を確認できない場合は、キュー名から推測せず、設定と実行ログを検証するまで本番処理へ進めません。
- [ ] Xcode、iOSシミュレーター、Appleの署名ツールを必要とする。
該当する場合はmacOS Agentへルーティングします。いずれも必要としない共通処理は、依存関係を確認したうえで別環境に残します。 - [ ] テストが信頼できる変更だけを扱い、署名資格情報を必要としない。
該当する場合は、その条件を満たすテスト用実行環境を選びます。署名資格情報を使う工程と同じ権限で動かす構成は避けます。 - [ ] 本番署名が必要である。
該当する場合は、署名用資格情報にアクセスできる実行主体、承認手順、ログ保護を個別に定めます。キューの分離だけで要件を満たしたとせず、主機と権限の分離まで確認します。 - [ ] Agentの稼働が端末での手動起動に依存している。
該当する場合は、サービス管理と再起動後の復旧試験が終わるまで、本番運用に進みません。
[ SECTION_05 ] ガバナンス：テスト、未信頼コード、署名を分ける
通常のビルド、未信頼のプルリクエスト、本番署名を必要とするリリースは、同じ信頼レベルの処理として扱わないでください。未信頼コードを実行するAgentへ本番署名の認証情報を渡すと、コードから秘密情報に到達する可能性があります。具体的なリスクと対策は、Buildkiteのセキュリティチェックリストと自社のアクセス制御を照らして評価します。
キューはタスクをAgentへ振り分ける仕組みです。キューを分けても、同じMac、同じmacOSユーザー、同じキーチェーン、同じ権限で実行していれば、ホストレベルの隔離が実現したとはいえません。未信頼コードと署名処理を同じ主機で扱う必要がある場合は、アクセス可能な資格情報、実行後の清掃、他ジョブへの影響を具体的に検証します。
責任範囲は、資格情報ごとに明確にします。Agent Tokenの管理、リポジトリ認証の管理、署名材料の保管、ジョブログのマスキングを、どのチームが承認し、更新し、監査するのかを記録してください。安全性の判断はキュー名ではなく、実際の実行ユーザー、主機、権限、資格情報へのアクセス経路に基づいて行います。
[ SECTION_06 ] 受け入れ：実プロジェクトの結果を証拠にする
最後は、実際のiOSプロジェクトを使って一連の処理を検証します。Agentのオンライン表示だけで合格にせず、ソース取得からXcode選択、ビルド、テスト、成果物の保管までをジョブログと結果で追跡します。
確認する項目は、主機と実行ユーザー、Agentの状態とログ、選択されたXcode、ビルド結果、テスト結果、成果物の保存先です。署名やアーカイブを含むリリース経路は、通常のテスト経路と分けて承認記録も残します。Appleのテスト実行と結果の解釈に関する説明を参照し、成功・失敗の判定がBuildkiteのログで追跡できる状態にします。
受け入れ時には、次の失敗条件も試します。意図したXcodeが選ばれない、Agentの再起動後に接続しない、成果物を取得できない、署名資格情報が不要なジョブから見える、といった状態です。障害時の連絡先、Agent更新の担当、ログの保管場所も運用記録に含めます。
Macを遠隔で用意する場合も、契約や構成を推測で補わず、利用可能な構成、料金、契約期間、設置地域、引き渡し方法、アクセス手段を事前に確認します。購入案との比較では、Mac miniの調達情報も参照し、保守を自社で担う範囲と外部に委ねる範囲を整理できます。
[ SECTION_07 ] FAQ：導入前に確認する項目
Buildkite Mac Agentを既存のiOSプロジェクトに接続するとき、最初に確認する項目は何ですか？
Xcodeに依存する工程を特定し、Agentの実行ユーザー、接続キュー、Xcodeの選択先を順に確認します。実プロジェクトのジョブログで、割り当て先と処理結果を照合してください。
自社管理のMac Agentは、どのmacOSユーザーで実行すべきですか？
作業領域、キーチェーン、成果物に必要な権限を持つ専用ユーザーを候補にします。実際の権限は、通常のテストと署名処理の要件を分けて検証し、管理者権限を安易に付与しないでください。
キューを分ければ、iOSテストと本番署名を隔離できますか？
キューの分離だけでは、主機、macOSユーザー、署名資格情報の隔離は保証されません。未信頼コードを扱う環境と本番署名を行う環境の実行主体や秘密情報へのアクセスを、別途設計して確認します。
Mac Agentが想定したXcodeを使っているか、どう確かめますか？
ジョブのログにxcode-select -pとxcodebuild -versionの出力を残し、対象プロジェクトのビルドとテスト結果を照合します。端末での確認だけで済ませず、Agent自身が実行する環境を検証してください。
[ SECTION_08 ] 運用要件に合わせてMacの持ち方を決める
自社購入のMacは、物理的な管理や長期の専有運用が必要な場合に向きます。一方で、調達の手続き、保守と更新、ピーク時以外の余剰容量を自社で引き受けることになります。まずは必要なアクセス方法、稼働責任、障害時の対応を整理し、遠隔Macを含む選択肢を比較してください。
短期の検証や追加のビルド環境が必要で、物理主機の購入・保守を避けたい場合は、NOVAKVMの遠隔Mac利用案内で提供条件を確認できます。長期にわたり高負荷で固定運用する場合や、物理インターフェースへの接続が必要な場合は、自社保有も比較対象に残し、実際の運用要件に合う方法を選びます。