Gestire una farm CI per Mac su Mac mini dedicati

L'unico numero che conta è quante build devono girare nello stesso momento nell'ora di punta. Non sviluppatori, non repository: build in parallelo.

Una stima indicativa che vale per la maggior parte dei team iOS:

Il segnale è il tempo in coda. Se nell'ora di punta le build aspettano più di un paio di minuti, aggiungi una macchina. Costa meno dell'ora che ogni sviluppatore passa ad aspettare.

Ogni Mac mini ti dà l'intera macchina: niente hypervisor, nessun vicino rumoroso. Questo ti offre due schemi validi.

La soluzione più pulita. Una build ha a disposizione tutta la CPU, la GPU e la memoria. Usala per le build Xcode e i test UI, dove una build si prende volentieri ogni core che le dai.

Funziona quando i job sono piccoli e limitati dall'I/O: unit test, linting, packaging. Su un M4 o M6 da 32 GB, due job leggeri in parallelo girano senza problemi.

Combinare i due schemi è normale: macchine pesanti dedicate alle build di release, macchine più leggere riempite di job veloci.

Assegna un'etichetta alle macchine e lascia che la pipeline indirizzi i job. Le divisioni utili:

ios-app, sdk, internal-tools. Ogni repository punta alla propria etichetta, così una build rotta su un prodotto non blocca mai un altro prodotto.

macchine pr veloci e sempre calde, macchine release che vengono inizializzate prima di ogni build firmata.

Le agenzie danno a ogni cliente le sue macchine, con le sue credenziali e i suoi certificati. Niente in comune, niente che possa trapelare da un account all'altro.

Tutto su un solo account MacDuty, con una sola fattura a fine mese.

Un Mac che compila da un anno accumula versioni di Xcode, simulatori e cache. Quando sposti una macchina su un nuovo progetto, chiedi all'assistenza una reinstallazione pulita. La facciamo solo con il tuo via libera, perché inizializza il Mac.

Stessa versione di Xcode su tutte le macchine di un pool, aggiornata in modo deliberato. Una farm in cui le macchine divergono produce build che passano su un runner e falliscono su un altro.

I grafici della CPU sulle macchine di build sono sempre allarmanti e raramente utili per decidere. Il tempo di attesa in coda ti dice quando aggiungere hardware.

Con dieci macchine, una ferma dovrebbe essere un fastidio, non un incidente.

Le piattaforme di orchestrazione aggiungono uno scheduling in stile Kubernetes sopra macOS virtualizzato, e quello strato lo paghi. È davvero utile se ti servono VM effimere avviate per ogni job su larga scala.

La maggior parte dei team sotto le venti macchine non ne ha bisogno. Gli servono pochi Mac veloci e dedicati che restano accesi, mantengono calde le cache e costano lo stesso ogni mese. Ecco cos'è una farm dedicata: macchine fisiche intere a prezzo fisso, con la cache di build ancora lì per il job successivo invece di essere buttata via insieme alla VM.

In più hai la differenza che si vede alle 2 di notte prima di un rilascio: chi gestisce i rack risponde all'email.

Descrivici la struttura: quante macchine, quali modelli, cosa va installato. Su richiesta le configuriamo con la tua versione di Xcode, l'agente del runner, le chiavi e i certificati, e gestiamo reinstallazioni e modifiche alla flotta man mano, ognuna con il tuo via libera.