Cum rulezi o fermă de CI pe Mac mini dedicate

Singurul număr care contează e câte build-uri trebuie să ruleze în același timp în ora ta cea mai aglomerată. Nu dezvoltatori, nu repo-uri: build-uri simultane.

O formă aproximativă, valabilă pentru majoritatea echipelor iOS:

Timpul de așteptare la coadă e semnalul. Dacă build-urile așteaptă mai mult de câteva minute la vârf, mai adaugă o mașină. E mai ieftin decât ora pe care o pierde fiecare dezvoltator așteptând.

La fiecare Mac mini ai toată mașina pentru tine: fără hypervisor, fără vecin zgomotos. De aici, două tipare care merg amândouă.

Cel mai curat. Un build primește tot CPU-ul, tot GPU-ul și toată memoria. Folosește varianta asta pentru build-uri Xcode și teste UI, unde un build mănâncă fericit fiecare nucleu pe care i-l dai.

Merge când joburile sunt mici și limitate de I/O: teste unitare, linting, împachetare. Pe un M4 sau M6 de 32 GB, două joburi ușoare în paralel stau lejer.

E normal să le combini: mașini puternice dedicate build-urilor de release, mașini mai ușoare încărcate cu joburi rapide.

Pune etichete pe mașini și lasă pipeline-ul să trimită joburile la ele. Împărțirile utile:

ios-app, sdk, internal-tools. Fiecare repo țintește propria etichetă, așa că un build stricat la un produs nu blochează niciodată altul.

mașini pr, rapide și mereu calde, mașini release, șterse înainte de fiecare build semnat.

Agențiile dau fiecărui client mașinile lui, cu credențialele și certificatele lui. Nimic în comun, nimic care să scape dintr-un cont în altul.

Totul pe un singur cont MacDuty, cu o singură factură la sfârșitul lunii.

Un Mac care face build-uri de un an adună versiuni de Xcode, simulatoare și cache-uri. Cere-ne o reinstalare curată când muți o mașină pe un proiect nou.

Aceeași versiune de Xcode pe fiecare mașină dintr-un pool, actualizată când decizi tu. O fermă în care mașinile ajung pe versiuni diferite produce build-uri care trec pe un runner și pică pe altul.

Graficele de CPU pe mașinile de build arată mereu alarmant și rar îți spun ce să faci. Timpul de așteptare la coadă îți spune când să mai adaugi hardware.

La zece mașini, una căzută trebuie să fie un inconvenient, nu un incident.

Platformele de orchestrare pun peste macOS virtualizat o planificare în stil Kubernetes, iar stratul ăla se plătește. Chiar e util dacă ai nevoie de VM-uri efemere, pornite pentru fiecare job, la scară mare.

Majoritatea echipelor sub douăzeci de mașini n-au nevoie. Au nevoie de câteva Mac-uri rapide și dedicate, care stau pornite, își țin cache-urile calde și costă la fel în fiecare lună. Asta e o fermă dedicată: mașini fizice întregi la preț fix, cu cache-ul de build încă acolo pentru jobul următor, în loc să fie aruncat odată cu VM-ul.

Mai primești și diferența care se vede la 2 noaptea, înainte de un release: oamenii care se ocupă de rack-uri răspund la email.

Spune-ne forma: câte mașini, ce modele, ce trebuie instalat pe ele. Vin configurate cu versiunea ta de Xcode, cu agentul de runner, cu cheile și certificatele tale, iar reinstalările și schimbările din flotă le facem noi pe parcurs.