Como manter uma farm de CI para Mac em Mac mini dedicados

O único número que importa é quantos builds precisam rodar ao mesmo tempo no seu horário de pico. Não desenvolvedores, não repositórios: builds simultâneos.

Uma estimativa aproximada que vale para a maioria das equipes iOS:

O tempo de fila é o sinal. Se os builds esperam mais do que alguns minutos no pico, adicione uma máquina. Sai mais barato do que a hora que cada desenvolvedor passa esperando.

Cada Mac mini é a máquina inteira só para você: sem hypervisor, sem vizinho barulhento. Isso permite dois padrões válidos.

O mais limpo. Um build fica com toda a CPU, a GPU e a memória. Use para builds do Xcode e testes de UI, em que um build consome sem problema todos os núcleos que você der a ele.

Funciona quando seus jobs são pequenos e limitados por I/O: testes unitários, lint, empacotamento. Em um M4 ou M6 de 32 GB, dois jobs leves em paralelo rodam com folga.

Misturar os dois é normal: máquinas pesadas dedicadas a builds de release, máquinas mais leves cheias de jobs rápidos.

Coloque labels nas suas máquinas e deixe o pipeline direcionar os jobs para elas. As divisões úteis:

ios-app, sdk, internal-tools. Cada repositório aponta para o próprio label, então um build quebrado em um produto nunca bloqueia outro.

máquinas pr, rápidas e sempre aquecidas, e máquinas release, apagadas antes de cada build assinado.

Agências dão a cada cliente as próprias máquinas, com as próprias credenciais e certificados. Nada compartilhado, nada para vazar entre contas.

Tudo isso em uma só conta MacDuty, com uma fatura no fim do mês.

Um Mac que faz builds há um ano acumula versões do Xcode, simuladores e caches. Quando você passar uma máquina para um novo projeto, peça ao suporte uma reinstalação limpa. Só fazemos com a sua autorização, já que isso apaga o Mac.

A mesma versão do Xcode em todas as máquinas de um pool, atualizada de propósito. Uma farm em que as máquinas vão divergindo produz builds que passam em um runner e falham em outro.

Gráficos de CPU em máquinas de build sempre assustam e raramente indicam o que fazer. O tempo de espera na fila diz quando adicionar hardware.

Com dez máquinas, uma fora do ar deve ser um incômodo, não um incidente.

Plataformas de orquestração colocam um agendamento no estilo Kubernetes por cima de macOS virtualizado, e você paga por essa camada. Ela é realmente útil se você precisa de VMs efêmeras criadas por job em grande escala.

A maioria das equipes com menos de vinte máquinas não precisa. Elas precisam de alguns Macs rápidos e dedicados que fiquem no ar, mantenham os caches aquecidos e custem o mesmo valor todo mês. É isso que uma farm dedicada é: máquinas físicas inteiras a preço fixo, com o cache de build ainda lá para o próximo job, em vez de ser jogado fora junto com a VM.

Você também tem a diferença que aparece às 2 da manhã antes de um release: quem cuida dos racks responde o e-mail.

Diga como ela deve ser: quantas máquinas, quais modelos, o que precisa estar instalado. Sob pedido, configuramos as máquinas com a sua versão do Xcode, o agente do runner, chaves e certificados, e cuidamos das reinstalações e das mudanças na frota conforme você precisar, cada uma com a sua autorização.