Grab的Mac Cloud退出为macOS CI/CD注入强劲动力

In our mission to optimize continuous integration and delivery (CI/CD), we have taken a bold step by relocating our infrastructure from a cloud vendor in the US to a colocation cluster within Southeast Asia, closer to our Git server infrastructure. This change has dramatically improved the performance of our macOS builds, primarily by reducing the network traffic delays associated with distant data centers. By bringing our infrastructure closer to home, we have not only accelerated CI/CD job completion times but also massively slashed operational costs.

在优化持续集成和交付（CI/CD）的使命中，我们大胆地将基础设施从美国的云供应商迁移到东南亚的共置集群，靠近我们的Git服务器基础设施。这一变化显著改善了我们的macOS构建性能，主要是通过减少与远程数据中心相关的网络流量延迟。通过将基础设施靠近家，我们不仅加快了CI/CD作业的完成时间，还大幅降低了运营成本。

Join us as we delve into the Mac Cloud Exit journey and the significant improvements it has brought to our workflows.

加入我们，深入了解 Mac Cloud Exit 之旅及其为我们的工作流程带来的显著改善。

Our macOS CI/CD infrastructure has evolved from 1 Physical Mac Pro running in our office to a cluster of 250 Mac minis fully occupied during peak hours of the day. There were multiple stages in the journey to transition to the current state. The following diagram shows the focus area for this blog post.

我们的 macOS CI/CD 基础设施已经从办公室运行的 1 台物理 Mac Pro 发展到高峰时段完全占用的 250 台 Mac mini 集群。在过渡到当前状态的过程中经历了多个阶段。以下图表显示了本博客文章的重点领域。

Figure 1. Infrastructure transition path

图1. 基础设施过渡路径

We began our journey with a much simpler setup.

我们开始我们的旅程时，设置要简单得多。

Figure 2. Photo of the setup when we started

图2. 我们开始时的设置照片

Today, that infrastructure has scaled significantly to meet the growing demands of Grab

如今，该基础设施已经显著扩展，以满足 Grab 不断增长的需求

Figure 3. Mac mini cluster today

图 3. 现在的 Mac mini 集群

At the beginning, it was a no-brainer to rent when our demand for macOS hardware increased from 1 MacPro to 20 times that size. However, when that grew to over 200 machines, the total cost became significant, prompting us to consider:

一开始，当我们对macOS硬件的需求从1台MacPro增加到20倍时，租赁显然是个明智的选择。然而，当数量超过200台时，总成本变得显著，这促使我们考虑：

1. What is the desired reliability for this cluster?
2. 该集群的期望可靠性是什么？
3. What would be the ...