専用のMac miniでMacのCIファームを運用する

重要な数字は1つだけです。最も混み合う時間帯に、同時にいくつのビルドを実行する必要があるか。開発者の数でもリポジトリの数でもなく、同時実行ビルド数です。

多くのiOSチームに当てはまるおおよその目安：

判断材料はキューの待ち時間です。ピーク時にビルドが2〜3分以上待つようなら、マシンを追加してください。開発者全員が待つ1時間よりも安く済みます。

各Mac miniはマシン全体がお客様のものです。ハイパーバイザーも、リソースを奪い合う隣人もいません。そのため、有効なパターンが2つあります。

最もすっきりした構成です。ビルドがCPU、GPU、メモリをすべて使えます。与えたコアをすべて使い切るXcodeビルドやUIテストに向いています。

ジョブが小さくI/Oバウンドな場合に有効です（ユニットテスト、lint、パッケージング）。32 GBのM4またはM6なら、軽いジョブ2つを並行して余裕をもって実行できます。

両方を組み合わせるのが普通です。重いマシンはリリースビルド専用にし、軽いマシンには短いジョブを詰め込みます。

マシンにラベルを付け、パイプラインからそのラベルに振り分けます。便利な分け方：

ios-app、sdk、internal-tools。各リポジトリが自分のラベルを指定するので、あるプロダクトのビルドが壊れても、別のプロダクトが止まることはありません。

高速で常にウォームな状態のprマシンと、署名付きビルドのたびに消去されるreleaseマシン。

エージェンシーは、クライアントごとに専用のマシンを用意し、認証情報と証明書も分けます。共有するものはなく、アカウント間で漏れるものもありません。

すべて1つのMacDutyアカウントで管理し、月末に請求書が1通届きます。

1年間ビルドを続けたMacには、Xcodeのバージョン、シミュレータ、キャッシュがたまります。マシンを新しいプロジェクトに回すときは、サポートにクリーンな再インストールを依頼してください。Macが消去されるため、お客様の承認があった場合にのみ実施します。

プール内のすべてのマシンで同じXcodeバージョンを使い、アップグレードは計画的に行います。マシンごとに環境がずれたファームでは、あるランナーでは通り、別のランナーでは失敗するビルドが生まれます。

ビルドマシンのCPUグラフは常に危なそうに見えますが、対処につながることはほとんどありません。ハードウェアを追加すべき時期は、キューの待ち時間でわかります。

10台あれば、1台が止まっても障害ではなく、ちょっとした不便で済むようにしておくべきです。

オーケストレーションプラットフォームは、仮想化したmacOSの上にKubernetes風のスケジューリングを重ねており、その層の分も料金に含まれます。大規模に、ジョブごとに使い捨てのVMを立ち上げる必要があるなら、確かに役立ちます。

20台未満のチームの多くには、その必要はありません。必要なのは、止まらず、キャッシュをウォームに保ち、毎月同じ金額で使える、高速な専有Macが数台です。専有ファームとはまさにそれです。物理マシンを丸ごと定額で使え、ビルドキャッシュはVMと一緒に捨てられることなく、次のジョブのために残ります。

リリース前の午前2時に差が出る点もあります。ラックを運用している担当者がメールに返信します。

台数、モデル、インストールが必要なものなど、構成をお知らせください。ご依頼があれば、指定のXcodeバージョン、ランナーエージェント、鍵、証明書を設定します。運用中の再インストールや台数構成の変更も、その都度お客様の承認を得たうえで対応します。