无需虚拟化即可在Mac OS上重现和包含CI
最近，我一直在研究Mac OS（特别是iOS）的持续集成的状态。 我想了解人们在Mac OS上如何进行CI，以及常见的最佳做法是什么。 不幸的是，对于我来说，没有什么惊喜，因为Mac OS的构建自动化状态非常糟糕。 在这篇博客文章中，我将总结一下我的发现，并描述我提出的实验性解决方案。
首先，我们需要弄清楚我们在寻找什么版本。 良好的CI设置通常旨在确保以下几点：
- 灵活可复制的环境 。 应该可以指定执行构建的环境。 不同类型的构建可能需要不同版本的工具和框架，CI应当保证某种类型的构建将始终在同一环境中执行。
- 隔离建筑物 。 顺序或并行构建不能相互干扰执行。 对于每个新构建，应从先前构建的工件中清除环境。
- 表现 。 与在开发人员的本地计算机上构建的CI相比，CI构建的性能应具有最小的影响。
常见的CI系统使用一种模式，在该模式下，执行构建AKA工作的计算机会安装一个称为CI代理的程序，该程序会不断拉动主服务器进行工作。
早在20年前，代理只是运行shell脚本，开发人员的工作是确保这些脚本编写正确并提供上述保证。 但是根本不可能做出脚本，最重要的是要保持这样的保证。
从那以后，不幸的是，并没有发生很多变化 。 该体系结构中最显着的变化是使用虚拟机作为CI工作者的转变，以拥有这种灵活且可复制的环境。 除此之外，设置CI系统甚至使用完全托管的解决方案变得更加容易。
这是Uber工程师的精彩演讲，内容涉及他们从一台物理Mac Mini到数千台虚拟机的旅程（始于13：20，Medium不支持时间标签）。 这篇演讲基本上展示了上述事物的整体演变。
这是一个./chamber.sh ./script/ci.sh脚本，可以像./chamber.sh ./script/ci.sh一样使用它来在./chamber.sh ./script/ci.sh中运行现有的CI脚本。
该脚本已经在多个项目上进行了测试，但仍然是WIP。 我强烈建议您尝试一下并报告任何问题。 不过，请阅读它，其中包含有关其功能以及如何调试/配置功能的详细注释。
运行虚拟机仍然很困难。 如果不是苹果公司，那么也许像Veertu这样具有现代Anka虚拟化技术的公司将为Mac OS的自动化带来类似Docker的感觉。 在此之前，人们将寻找解决方法和黑客手段。
本文中介绍的Chamber概念只是一个有趣的想法，似乎适用于一些中小型项目。 但这是实验性的 。 仍然存在一些问题：
- 测试各种项目。
- 使
xcodebuild在nix-shell。 我无法使其正常运行，因此使用nix-shell来计算用于在沙箱中运行脚本的PATH。 - 目前尚不清楚如何支持多个Xcode版本。 应该是Nix包装吗？ 它应该是一个单独的工具吗？
我希望这是一个有趣的阅读。 如有任何疑问，请随时在Twitter上对我进行ping操作。 我希望可以从我的研究和Chamber实验中学到一些有用的东西。