再現可能な環境
Xcode、Command Line Tools、依存関係のロックファイル、クリーンアップコマンドを固定します。バージョンを変更するときは、別の作業ディレクトリで検証してから本番キューに反映します。
バージョンとロックファイル
再利用できるビルド構成例
各デリバリーフローにおけるクラウドMacの役割
以下は導入事例ではなく、未検証の効果を保証するものでもありません。実行のきっかけ、専有物理マシン上のタスク、署名の責任範囲、ログの保存先、成果物の受け渡し先を整理しました。リポジトリや権限モデルに合わせて、チームで再利用できます。
5つのフロー
ビルド、配信、検証に対応
専有ノード1台
ワークロードを順番に実行
4つの管理項目
コード、認証情報、ログ、成果物を個別管理
BUILD PASSPORT
iOS Release / Main
RUN-042
01
コードのコミット
リポジトリのイベントでジョブを起動
受信済み
02
依存関係とキャッシュ
ロックファイルから復元し、ヒット状況を記録
完了
03
Xcode Archive
専有物理マシンでアーカイブを作成
実行中
04
チェックと受け渡し
署名を確認して管理下の成果物を出力
未処理
ジョブキュー
MAIN → RELEASE → HOTFIX
ジョブごとに作業ディレクトリを分離
署名の健全性チェック
設定を照合
機密情報はチームで管理
活用方法
責任範囲を決めてから自動化の手順を取り入れる
リファレンス構成では、タスクの流れだけを示しています。リポジトリ権限、署名情報、開発者アカウント、リリース承認、成果物の保管期間は、利用するチームが定めてください。
認証情報をリポジトリに含めない
トークン、証明書、プロビジョニングプロファイルは、管理された方法で注入します。ログには問題の特定に必要な情報のみを残し、出力前にパス、トークン、非公開リポジトリのURLを削除します。
最小権限成果物の受け渡し先を明確に
Archive、エクスポートしたパッケージ、シンボルファイル、テストレポートに個別の名前を付け、コミット情報を添えます。受け渡し後は、チームの方針に従ってノード上の一時ファイルを削除します。
管理されたエクスポート
アプリの自動ビルド
コミットからレビュー可能な成果物まで、5段階で受け渡し
CDNMac M4をセルフホストランナーとして登録し、リポジトリのイベントでジョブを起動する構成です。最終成果物は、チームのレビューや後続の配信システムに引き渡せます。
01
コードのコミット
起動元：開発者またはマージ処理
メインブランチまたはリリースタグを起点にキューを実行します。ジョブの開始時にコミットハッシュ、ブランチ、起動元、対象Schemeを記録し、機密変数はログに出力しません。
保存先：専有物理マシンの隔離された作業ディレクトリ
02
依存関係の復元
起動元：実行スクリプト
ロックファイルを基に、Swift Package、CocoaPodsなどの依存関係を復元します。キャッシュキーには最低限、ロックファイルのハッシュとツールのバージョンを含め、古いキャッシュが別バージョンに影響しないようにします。
保存先：バージョン別キャッシュディレクトリと依存関係ログ
03
Xcode Archive
起動元：ビルドジョブ
workspace、scheme、configuration、destinationを明示してアーカイブを作成します。失敗時は終了コード、主要ログ、結果パッケージを保存します。
保存先：コミット情報付きのArchiveディレクトリ
04
署名チェック
起動元：リリースジョブ
Bundle Identifier、チーム、証明書の有効性、プロビジョニングプロファイルとの整合性を確認します。開発者アカウントと署名資産は、常にユーザーのチームが管理します。
保存先：レビュー用チェックリスト。認証情報は平文で出力しない
05
成果物のアーカイブ
起動元：受け渡しスクリプト
インストールパッケージ、シンボルファイル、ビルド概要、チェックサムを出力し、チーム管理下のストレージにコピーします。受け渡しを確認したら一時ディレクトリを削除します。
保存先：管理されたストレージとチームのレビューキュー
複数ブランチのキュー
専有物理マシン1台で、3種類のブランチをルールに沿って実行
専有環境でも、すべてのジョブを同時に実行できるわけではありません。CDNMac M4を1台使う場合は、優先度、作業ディレクトリ、クリーンアップの範囲を明確にし、リリース作業と日常の検証が互いに影響しないようにします。
MAIN
継続的な検証
メインブランチ
マージ後に単体テスト、静的解析、基本的なArchiveを実行します。キャッシュは再利用できますが、DerivedDataはプロジェクトとXcodeのバージョンごとに分離します。
- 優先度
- 通常
- 作業ディレクトリ
- work/main
- 終了時のクリーンアップ
- 未追跡ファイルを削除
RELEASE
リリース候補
リリースブランチ
キューに追加したら、同じリポジトリの不要なジョブを一時停止します。署名チェックとエクスポートには専用の設定を使い、成果物の概要をチームでレビューします。
- 優先度
- 高
- 作業ディレクトリ
- work/release
- 終了時のクリーンアップ
- 一時キーチェーンを削除
HOTFIX
手動承認
修正ブランチ
責任者の確認後にキューへ追加します。問題の解決に必要なキャッシュだけを復元し、ビルド後に一時変数を削除して、切り戻し用の基準点を記録します。
- 優先度
- 手動承認
- 作業ディレクトリ
- work/hotfix
- 終了時のクリーンアップ
- キューと基準点を復元
キューのルール
成果物を書き込み中のジョブを、リリースジョブで割り込ませないようにします。失敗したジョブはログを収集してから作業ディレクトリを解放し、すべてのジョブ終了時に何度実行しても安全なクリーンアップを行います。
MAIN
RELEASE
HOTFIX
CLEAN
FLUTTER IOS
クロスプラットフォームの依存関係とXcodeの工程を分けて記録
Flutter iOSでは、依存関係の復元、CocoaPods、Xcodeビルドに待ち時間が分散しがちです。工程を分けて記録すれば、キャッシュが有効か、どの層で失敗したかを判断できます。
工程ごとの境界
各工程で個別のログと終了コードを出力します。前の工程が成功した場合にのみ、次の工程でその成果物を読み込み、依存関係の問題をXcodeのコンパイルエラーと誤認しないようにします。
- Flutter SDKとプロジェクトの要件を先に確認します。
- ロックファイルのハッシュをキャッシュキーに含めます。
- PodsとDartのキャッシュは別々に無効化します。
- エクスポートしたパッケージとシンボルファイルは個別に受け渡します。
01
依存関係の復元
キャッシュ：Dartパッケージディレクトリ
プロジェクトの依存関係を復元し、SDKのバージョンとロックファイルのハッシュを記録します。
02
CocoaPods
ログ：Podsのインストール出力
Podfile.lockに基づいてiOSネイティブの依存関係をインストールし、整合しないPodsは再利用しません。
03
Xcodeビルド
成果物：Archiveと結果パッケージ
workspace、scheme、configurationを指定してArchiveを実行します。
04
成果物のエクスポート
保存先：チーム管理下のストレージ
署名を確認してからエクスポートし、コミット情報とチェックサムを生成します。
キャッシュがヒットしても、該当ディレクトリとキーを再利用できることを示すだけで、ビルド全体が必ず速くなるとは限りません。Flutter、CocoaPods、Xcode、ロックファイルを更新したら、キャッシュの範囲を再検証してください。
TESTFLIGHT配信
ビルド成果物はチームのレビュー後に配信フローへ
クラウドMacはビルド成果物の生成とチェックを担いますが、チームのリリース承認に代わるものではありません。開発者アカウント、署名資産、バージョン情報、配信の判断はすべてユーザーが管理します。
-
01
候補となる成果物を作成
リリースブランチでArchiveとエクスポートを実行し、コミットハッシュ、バージョン、ビルド番号、シンボルファイル、チェックサムを添付します。
-
02
チームでレビュー
責任者が変更範囲、署名の整合性、プライバシー情報、権限の用途、テスト結果を確認します。不承認の場合は、該当するコミットから再ビルドします。
-
03
配信フローへ進む
承認後、チーム管理下のリリースジョブで制限付きの認証情報を使ってアップロードします。機密情報をリポジトリや通常のビルドログに保存しないでください。
-
04
受け渡し結果を記録
成果物の識別情報、レビュー結果、必要なログを保存します。受け渡し後は、ノード上の一時エクスポートファイルと一時認証情報を削除します。
CDNMacノードが担当
ビルド、アーカイブ、署名の整合性チェック、成果物のエクスポート
ユーザーのチームが担当
アカウント管理、署名資産、リリース承認、配信情報、コンプライアンス判断
APPLE SILICONでのAI検証
モデルの互換性を検証し、性能を保証する表現は避ける
CDNMac M4はM4、16GB RAM、256GB SSDを搭載しています。ローカルでのモデル互換性検証やプロトタイプのテストに適していますが、モデル、コンテキスト、データ、メモリの要件を事前に確認してください。
データを準備
実験に必要なデータだけを同期し、出所とバージョンを記録します。機密データは事前に匿名化し、元データ、中間データ、出力結果を別々のディレクトリで管理します。
- 入力
- バージョン管理されたサンプル
- 復元ポイント
- 元データの読み取り専用コピー
実行環境を確認
macOS、ランタイム、フレームワーク、モデル形式を記録します。まず少量のデータで読み込み、推論、メモリ使用量を確認してから、実験の範囲を広げます。
- チェック項目
- バージョンと空きメモリ
- 復元ポイント
- 固定した依存関係一覧
結果をエクスポート
実験パラメーター、結果の概要、必要なログを出力し、機密データ全体をレポートに含めないようにします。利用期間の終了前に、必要な結果を管理下のストレージへコピーします。
- 出力
- パラメーター、概要、ログ
- 注意事項
- 特定のスループットは保証しません
構成の確認
モデル、コンテキスト、中間データを16GB RAMで安定して扱えない場合や、記載のないチップ・メモリ構成が必要な場合は、事前にサポートチームへご相談ください。プロトタイプが動作しても、本番環境の処理能力が検証されたことにはなりません。
実験環境を相談する
チームの振り返りに使える表現例
ワークフローの価値を、確認可能な技術的事実で伝える
以下は、社内の振り返りに使える役割別の表現例です。特定の顧客の評価、スコア、企業による推薦を示すものではありません。
「私が重視するのは、キューが自分たちのチーム専用かどうかと、失敗時に原因を特定できるログが残るかどうかです。ビルド速度を漠然と語るより、作業ディレクトリと成果物の保存先を明確にするほうが役立ちます。」
モバイル開発責任者
「ブランチのジョブが同じ物理マシンを使うなら、優先度、キャッシュキー、クリーンアップの設計が重要です。専有リソースで基本的な分離はできますが、パイプラインは私たちが設計する必要があります。」
CIプラットフォームエンジニア
「タイムゾーンをまたいで接続する場合、リモートアクセス、バックグラウンドビルド、成果物のエクスポートをそれぞれ独立させたいです。そうすれば、ローカルのネットワークが一時的に不安定になっても、実行中のビルドに影響しません。」
個人開発者
ワークフローを再現
準備項目、環境変数、失敗時の切り戻しポイント
再現を始める前に、最小構成で動作するバージョンを用意します。環境変数名はチームの規約に合わせて変更できますが、機密値はリポジトリにコミットせず、ビルドログにも出力しないでください。
| ワークフロー | 準備項目 | 環境変数 | 失敗時の切り戻しポイント |
|---|---|---|---|
| アプリの自動ビルド | リポジトリへのアクセス、Xcodeのバージョン、Scheme、依存関係のロックファイル、エクスポート設定 | REPO_REF BUILD_SCHEME EXPORT_PATH |
結果パッケージとコミット情報を保存し、一時キーチェーンを削除して、最後にビルドできたコミットに戻す |
| 複数ブランチのビルド | ブランチの優先度、個別の作業ディレクトリ、同時実行数の制限、冪等なクリーンアップスクリプト | BRANCH_NAME RUN_PRIORITY WORK_ROOT |
後続のキューを停止し、現在のログを保存して、クリーンな作業ツリーと元のキュー順に戻す |
| Flutter iOS | Flutterのバージョン、Podfile.lock、Xcode workspace、キャッシュキーのルール | FLUTTER_ROOT PODS_CACHE_KEY IOS_SCHEME |
工程ごとにキャッシュを無効化し、再利用できるログは残して、直近で成功した工程から再実行する |
| TestFlight配信 | リリース承認、バージョン情報、署名の整合性、成果物の検証、チーム管理下の認証情報 | RELEASE_VERSION BUILD_NUMBER ARTIFACT_PATH |
配信ジョブを停止し、一時認証情報を失効させて、レビュー用チェックリストに戻り、候補成果物を再生成する |
| AI検証 | モデル形式、少量のサンプルデータ、ランタイムのバージョン、メモリ使用量の確認、エクスポート先 | MODEL_PATH DATASET_PATH RESULT_PATH |
パラメーター一覧と結果概要を保存し、固定した依存関係に戻して、元データの読み取り専用コピーを使用する |
01
まず最小構成で実行
リポジトリ、Scheme、出力先をそれぞれ1つに絞り、ノードで一連の処理が完了することを確認します。
02
次に機密変数を設定
管理された方法で最小権限の認証情報を注入し、ログのマスキング、有効期限、ローテーションの手順を検証します。
03
最後にキューを拡張
ブランチを増やす前に、優先度、タイムアウト、失敗時の回収、作業ディレクトリのクリーンアップルールを設定します。