전용 Mac mini로 Mac CI 팜 운영하기

중요한 숫자는 하나뿐입니다: 가장 바쁜 시간대에 동시에 실행되어야 하는 빌드 수입니다. 개발자 수도, 저장소 수도 아닌 동시 빌드 수입니다.

대부분의 iOS 팀에 들어맞는 대략적인 구성:

대기 시간이 신호입니다. 피크 때 빌드가 몇 분 넘게 기다린다면 머신을 추가하세요. 모든 개발자가 기다리며 보내는 한 시간보다 저렴합니다.

각 Mac mini는 머신 전체를 고객의 작업에 씁니다: 하이퍼바이저도, 자원을 나눠 쓰는 이웃도 없습니다. 그래서 유효한 패턴이 두 가지 있습니다.

가장 깔끔합니다. 빌드가 CPU, GPU, 메모리 전체를 씁니다. Xcode 빌드와 UI 테스트에 쓰세요. 이런 빌드는 주어진 코어를 모두 기꺼이 소모합니다.

작업이 작고 I/O 위주일 때 적합합니다: 유닛 테스트, 린트, 패키징. 32 GB M4 또는 M6에서는 가벼운 작업 두 개를 병렬로 돌려도 여유가 있습니다.

둘을 섞는 것도 일반적입니다: 무거운 머신은 릴리스 빌드 전용으로, 가벼운 머신에는 빠른 작업을 몰아서 씁니다.

머신에 라벨을 붙이고 파이프라인이 그 머신으로 작업을 보내게 하세요. 유용한 분할 방식:

ios-app, sdk, internal-tools. 저장소마다 자체 라벨을 지정하므로, 한 제품의 빌드가 깨져도 다른 제품을 막지 않습니다.

빠르고 항상 준비된 pr 머신, 서명 빌드 전마다 지우는 release 머신.

에이전시는 고객사마다 자체 자격 증명과 인증서를 가진 전용 머신을 줍니다. 공유하는 것이 없으니 계정 사이에 새어 나갈 것도 없습니다.

이 모든 것이 MacDuty 계정 하나에 있고, 월말에 인보이스 하나로 청구됩니다.

1년 동안 빌드를 해 온 Mac에는 Xcode 버전, 시뮬레이터, 캐시가 쌓입니다. 머신을 새 프로젝트로 돌릴 때는 지원팀에 클린 재설치를 요청하세요. Mac이 지워지므로 고객의 승인이 있을 때만 진행합니다.

풀의 모든 머신에서 같은 Xcode 버전을 쓰고, 업그레이드는 의도적으로 합니다. 머신마다 버전이 어긋나는 팜에서는 한 Runner에서는 통과하고 다른 Runner에서는 실패하는 빌드가 나옵니다.

빌드 머신의 CPU 그래프는 늘 불안해 보이지만 조치할 근거가 되는 경우는 드뭅니다. 하드웨어를 추가할 시점은 대기열 대기 시간이 알려 줍니다.

머신이 10대라면 한 대가 멈춘 것은 장애가 아니라 불편 정도여야 합니다.

오케스트레이션 플랫폼은 가상화된 macOS 위에 Kubernetes 방식의 스케줄링을 얹고, 그 계층에 비용을 지불하게 됩니다. 대규모로 작업마다 임시 VM을 띄워야 한다면 실제로 유용합니다.

머신 20대 미만인 팀 대부분은 그렇지 않습니다. 이들에게 필요한 것은 계속 켜져 있고, 캐시가 따뜻하게 유지되며, 매달 같은 비용이 드는 빠른 전용 Mac 몇 대입니다. 전용 팜이 바로 그것입니다: 고정 가격의 물리 머신 전체이고, 빌드 캐시는 VM과 함께 버려지지 않고 다음 작업을 위해 남아 있습니다.

릴리스 전 새벽 2시에 드러나는 차이도 있습니다: 랙을 운영하는 사람이 이메일에 답합니다.

구성을 알려 주세요: 머신 수, 모델, 설치해야 할 것. 요청하시면 고객의 Xcode 버전, Runner 에이전트, 키와 인증서로 설정해 드리고, 이후 재설치와 머신 구성 변경도 매번 고객의 승인을 받아 처리합니다.