Una granja de CI de Mac con Mac mini dedicados

La única cifra que importa es cuántos builds deben ejecutarse a la vez en su hora de más carga. No desarrolladores, no repositorios: builds simultáneos.

Una estimación aproximada que vale para la mayoría de los equipos de iOS:

El tiempo en cola es la señal. Si los builds esperan más de un par de minutos en el pico, añada una máquina. Sale más barato que la hora que cada desarrollador pasa esperando.

Cada Mac mini es una máquina entera para usted: sin hipervisor, sin vecinos ruidosos. Eso le da dos patrones válidos.

Lo más limpio. Un build recibe toda la CPU, la GPU y la memoria. Úselo para builds de Xcode y tests de UI, donde un build se come sin problema todos los núcleos que le dé.

Funciona cuando sus jobs son pequeños y limitados por E/S: tests unitarios, linting, empaquetado. En un M4 o M6 de 32 GB, dos jobs ligeros en paralelo van holgados.

Combinar ambos es normal: máquinas para cargas pesadas dedicadas a los builds de release y máquinas más ligeras llenas de jobs rápidos.

Etiquete sus máquinas y deje que el pipeline dirija los jobs hacia ellas. Las divisiones útiles:

ios-app, sdk, internal-tools. Cada repositorio apunta a su propia etiqueta, así que un build roto en un producto nunca bloquea otro.

Máquinas pr, rápidas y siempre en caliente; máquinas release, que se borran antes de cada build firmado.

Las agencias dan a cada cliente sus propias máquinas con sus propias credenciales y certificados. Nada compartido, nada que pueda filtrarse entre cuentas.

Todo en una sola cuenta de MacDuty, con una factura a final de mes.

Un Mac que lleva un año compilando acumula versiones de Xcode, simuladores y cachés. Cuando pase una máquina a un proyecto nuevo, pida a soporte una reinstalación limpia. Solo la hacemos con su visto bueno, porque borra el Mac.

La misma versión de Xcode en todas las máquinas de un grupo, actualizada de forma deliberada. Una granja en la que las máquinas se desalinean produce builds que pasan en un runner y fallan en otro.

Las gráficas de CPU de las máquinas de build siempre parecen alarmantes y casi nunca indican qué hacer. El tiempo de espera en cola le dice cuándo añadir hardware.

Con diez máquinas, que una esté caída debería ser una molestia, no un incidente.

Las plataformas de orquestación añaden una planificación al estilo de Kubernetes sobre macOS virtualizado, y usted paga esa capa. Es realmente útil si necesita VM efímeras creadas por cada job a gran escala.

La mayoría de los equipos con menos de veinte máquinas no lo necesitan. Necesitan unos pocos Mac rápidos y dedicados que sigan en marcha, mantengan sus cachés en caliente y cuesten lo mismo cada mes. Eso es una granja dedicada: máquinas físicas enteras a precio fijo, con la caché de build todavía ahí para el siguiente job en lugar de tirarse junto con la VM.

También tiene la diferencia que se nota a las 2 de la madrugada antes de una release: las personas que gestionan los racks responden al correo.

Cuéntenos cómo la quiere: cuántas máquinas, qué modelos y qué hay que instalar en ellas. Si lo pide, las configuramos con su versión de Xcode, el agente del runner, sus claves y certificados, y nos encargamos de las reinstalaciones y los cambios en la flota sobre la marcha, cada uno con su visto bueno.