spring 引入zuul

是一款很棒的软件。 作为执行和自动化引擎，它是您将发现的最好的引擎之一。 詹金斯（Jenkins）是无数个持续集成（CI）系统中的关键组件，这证明了其社区多年来建立的价值。 但这就是它的组成部分。 Jenkins本身不是CI系统。 它只是为您服务。 它确实做得很好，并具有各种内置功能和充满活力的插件生态系统，可帮助您告诉它运行的内容，时间和位置。

从最根本的意义上讲，CI就是将多个软件开发流的工作集成到一个连贯的整体中，并尽可能多地发生频率和尽可能少的摩擦。 Jenkins本身不知道您的源代码或如何将其合并在一起，也不知道如何向您和您的同事提供建设性反馈。 当然，您可以将其与其他可执行这些活动的软件粘合在一起，这就是Jenkins整合了许多CI系统的原因。

至少在一开始，这也是我们为OpenStack所做的。

如果没有测试，那就坏了

2010年，形成了一个名为开源项目社区。 引入了一些协助协作基础架构的开发人员，他们还从事了一个名为的免费数据库项目，该社区中的一个主要理念是“如果不进行测试，就意味着它被打破了”。 因此，OpenStack在第一天就要求对软件的所有建议更改进行审查并测试其回归，然后才能将其批准合并到任何源代码存储库的主干中。 为此，Hudson（后来分叉成立了Jenkins项目）被配置为运行测试以进行所有更改。

安装了一个插件以与代码检查系统交互，在提出新更改时自动触发作业，并通过检查注释进行报告，以指示它们是成功还是失败。 以今天的标准来看，这听起来似乎很初级，但是在当时，这是开源协作的革命性进步。 在CI看来，OpenStack上的任何开发人员都不是特别的，每个人的更改都必须通过不断增长的测试才能合并，这一概念被称为“项目门控”的项目。

但是，这种门控概念存在一个新出现的缺陷：为了确保两个不相关的更改不会以功能不兼容的方式更改某个软件，必须对它们进行一次顺序测试，然后才能合并。 即使在那时，OpenStack的安装和测试都很复杂，并且Swift普及。 开发人员贡献的增加以及测试覆盖率的提高意味着在繁忙时期，没有足够的时间来测试通过审核的每个变更。 一些较长时间的工作需要将近一个小时才能完成，因此，每天可以通过门口更换的大概上限是二十次。 产生的合并积压表明需要新的解决方案。

输入Zuul

在2012年5月的OpenStack CI会议上，CI团队成员之一James Blair 他“将从事Jenkins工作的投机执行”。 推测执行是现代微处理器流水线中最常见的优化。 就像与处理器硬件的类比一样，该理论是通过乐观地预测最近批准但尚未完成测试的变更的正面门控结果，随后批准的变更可以同时进行测试，然后有条件地合并，只要其前辈也通过了测试并合并。 詹姆斯说他为这个智能调度程序起了个名字： 。

在此时间范围内，尝试对Jenkins的XML作业配置执行更好的修订控制带来的挑战导致了基于人类可读的基于YAML的模板引擎的创建。 Jenkins的JClouds插件取得的成功有限，并且尝试使用作业刷新一次性Jenkins从属的云映像的繁琐尝试以创建服务结束。 有限的日志存储功能导致该团队添加了单独的外部解决方案来组织，提供服务和为作业日志建立索引，并假设维护了一个废弃的安全复制协议（SCP）插件，从而取代了Jenkins开箱即用的不太安全的FTP选项。 OpenStack基础架构团队正在围绕詹金斯（Jenkins）缓慢建立服务和实用程序的队伍，但开始遭遇性能限制。

乘詹金斯

到2013年年中，Nodepool不断回收多达100个在Jenkins中注册为从机的虚拟机，但这已经不足以应付不断增长的工作量。 詹金斯中全局锁的线程争用阻止了所有试图超过此阈值的尝试，无论在主服务器上投入了多少处理器能力和内存。 该项目提供了为詹金斯（Jenkins）奴隶捐款的额外能力，以帮助减轻频繁的工作积压，但这将需要一名额外的詹金斯（Jenkins）主人。 多个主机之间的有效分工需要一种新的沟通渠道，以调度和协调工作。 Zuul的维护者认为作业服务器协议是理想的选择，因此他们为Zuul安装了新的服务，并为Jenkins扩展了定制的Gearman客户插件。

现在，工作分散在越来越多的Jenkins大师团队中，因此不再有单个仪表板可以完整地查看工作活动和结果。 为了促进这个新的多主机世界，Zuul发展了自己的状态API和WebUI，以及通过协议发出指标的功能。 在接下来的几年中，Zuul逐渐包含了用户依赖的更多CI功能，而Jenkins在系统中的位置也相应下降，这已成为一种责任。 OpenStack成为早期选择Python编程语言的标准。 这在Zuul的开发中得到了体现，但是Jenkins及其插件是用Java实现的。 Zuul的配置以与OpenStack用于模板化其自己的Jenkins作业相同的YAML序列化格式进行维护，而Jenkins则将所有内容都保留在巴洛克式XML中。 这些差异使正在进行的维护变得复杂，并导致相关社区的新管理员不必要地陡峭的学习曲线，他们开始尝试运行Zuuls。

是时候进行另一场革命了。

Ansible的崛起

在2016年初，Zuul的维护者开始对其增长的服务团队进行为期一年的雄心勃勃的大修，目的是从整体系统设计中消除Jenkins。 到那时，Jenkins仅充当通过SSH在从属节点上运行主要由外壳脚本组成的作业的渠道，从而提供作业输出的实时流，并将生成的工件复制到长期存储中。 发现非常适合该第一个需求。 它是专门为通过SSH远程运行命令而构建的，就像Zuul一样，它是用Python编写的，并且还使用YAML来定义其任务。 它甚至具有内置模块，这些模块用于该团队以前作为定制Jenkins插件实现的功能。 Ansible开箱即用地提供了真正的多节点支持，因此相同的剧本可用于模拟和执行复杂的生产部署。 不断扩展的第三方模块生态系统填补了所有空白，其方式与Jenkins社区以前使用的插件相同。

，是Ansible命令输出模块扩展中的实时流。 一旦不再需要将工作限制在Jenkins的解析器可以理解的范围内，Zuul便可以自由地开发新功能，例如分布式存储库中的工作定义，可在项目之间共享，具有继承性和对秘密的安全处理以及测试能力。推动工作本身的拟议变更。 詹金斯（Jenkins）达到了它的目的，但至少对于Zuul来说，它的用处终于告一段落。

测试未来

Zuul的社区喜欢说它通过其投机执行的新颖应用“检验了未来”。 令人困惑的日子已经过去了，怀疑要对现有工作进行的改进是否会使它在生产中应用后会失效。 庞大的中央工作库的审查团队已经过时了。 作业被视为软件的一部分，并与其余的源代码一起发送，利用了Zuul的其他功能（例如跨存储库依赖项），以便您可以通过建议的作业来执行对一个项目中的部分工作的更改在另一个项目中进行更改。 它甚至会评论您的工作变更，突出显示存在语法问题的特定行，就像是另一位代码审阅者为您提供建议一样。

这些是Zuul以前梦dream以求的功能，但需要Jenkins解放，以便可以将工作解析交给自己。 这是CI的未来，Zuul的用户正在生活中。

截至2019年初，OpenStack基金会将Zuul确认为具有自己的身份和繁荣社区的独立，开放治理的项目。 如果您喜欢开源CI，请考虑一下。 Zuul的下一版开发一直在进行中，欢迎您的帮助。 在上找到更多 。

翻译自:

spring 引入zuul