在运行 Rubocop 风格的规则、Brakeman 安全扫描和模型控制器系统测试之间，我们基于远程 BuildKite 的持续集成设置需要大约 5 分 30 秒来验证代码更改是否已准备好交付 HEY。 我的基于 Intel 14900K 的 Linux 机器可以在不到一半的时间内完成此操作（而且我的 M3 Max 也没有慢多少！）。 因此，我们将放弃远程运行程序，而将持续集成带回到 37signals 的开发人员机器上。
在过去五到七年左右的时间里，多核开发机器所取得的巨大飞跃是引人注目的。 在不久之前，在本地计算机上在合理的时间内运行所有这些检查和验证还是不可想象的。 但 14900K 有超过 20 个核心，M3 Max 有 16 个核心，甚至最低级的 M2 MacBook 有 8 个。它们都能够执行大量并行工作，这些工作在 2010 年代中期在本地完成似乎是不可思议的。
HEY 也是一个相当丰富的代码库。 大约 55,000 行 Ruby 代码，经过大约 5,000 个测试用例以及另外 300 多个系统测试的验证。 事实上，所有这些测试都会经过全栈并访问数据库。 这些并没有被嘲笑到极点。
对我来说，现代开发者 CPU 性能改进中最令人满意的部分是可以简化我们的堆栈。 安装、操作和维护远程 CI 设置非常复杂。 要么您在自己的硬件上执行此操作，并直接处理这种复杂性，要么您花大价钱购买基于云的设置。 将所有这些都冲入简化的下水道是一个惊人的进步。
一如既往，简化的未来并不是均匀分布的。 我看不到像 Shopify 或 GitHub 这样的公司能够很快在本地对其数百万行代码运行全套测试。 但 99.99% 的网络应用程序在广度上更接近 HEY，而不是那些庞然大物。 小团队应该移除所有可能的活动部件。 永远不要追求比应用程序所需的更复杂的堆栈。
因此，一旦我们到达了另一边，我们就需要继续烧毁这些复杂性的桥梁。 我迫不及待地想点燃 37signals 的每一个远程持续集成桥。 进步是篝火。
1714476567
#我们正在将持续集成移回到开发人员机器上
2024-04-29 18:40:53
