这是一系列blog文章的一部分，CloudBees的技术专家总结了Jenkins用户会议（JUC）的演示文稿。这篇文章是由CloudBees的解决方案架构师Tracy Kennedy撰写的，关于JUC波士顿版权清除中心Dan Stine所做的演示。在一个开发人员不断搅动代码更改而Jenkins每天都在构建这些更改的世界中，还需要以同样快的方式启动这些构建的测试环境。为了满足这一需求，我们看到了一种将"基础设施视为代码"的趋势。这不仅仅是简单的BAT文件和shell脚本，相反，"基础设施即代码"意味着您可以自动配置环境的所有方面，包括基础结构和操作系统层，以及使用Chef、Ansible和Puppet等工具进行基础设施编排。这些工具的自动化脚本像应用程序代码一样受版本控制，甚至可以与应用程序代码本身集成。虽然配置管理工具至少可以追溯到20世纪70年代，但这种像应用程序代码一样处理基础结构代码的方法要新得多，至少可以追溯到90年代的CFEngine。即便如此，这些声明性配置工具直到2011年底才开始流行：基础设施CI基础设施代码的兴起为Jenkins创造了一个新的用例：作为组织基础设施的CI工具。在2014年波士顿詹金斯用户大会上，版权审查中心的丹·斯汀介绍了他和他的组织如何应对这一挑战。据斯廷称，版权清理中心的平台工作始于2011年。他们将"基础设施即代码"视为解决"可怜的IT操作人员"困境的答案，后者被迫手动部署和管理所有东西。 斯廷把IT运营人员比作凤凰城项目中臭名昭著的"布伦特"：他们所有的部署都取决于他，而他却不堪重负，成为他们瓶颈的根源。为了解决这个问题，他们设定了两个目标来改进部署过程：减少工作量提高部署的速度、可靠性和频率詹金斯和厨师至于实现这一目标的工具，组织专门挑选了Jenkins和Chef，因为他们对Jenkins已经很熟悉和熟悉，并且知道这两个工具背后都有很好的社区他们。他们还使用Jenkins与Liquibase协调执行模式更新，因为Jenkins是一个很好的通用作业执行器。他们将Chef客户机安装到在Chef服务器上注册的节点上。然后，开发人员将在他们的工作站上编写代码，并使用Chef's"刀子"等工具与服务器交互。他们的厨师代码存储在GitHub中，他们将烹饪书推送到Chef服务器。对于Jenkins，他们将为每个应用程序组分配自己的Cookbook CI作业和Cookbook release作业，它们将由与应用程序的构建作业相同的主机运行。每当合并新的基础结构代码时，CookbookCI作业都会运行。 他们还引入了一个新的奴隶类，其中安装了烹饪书作业所需的RubyGems，Chef拥有Chef服务器的凭证。Cookbook CI作业和AWS集成测试CookbookCI作业首先提示使用JSON、Ruby和Chef对代码的语法进行静态分析，然后使用kitchen-ec2插件以模拟应用程序实际部署拓扑的方式启动ec2实例进行集成测试。每个EC2实例都是从Amazon机器映像中创建的，该映像使用Ruby和Chef进行了预配置，每个实例都被标记以便于跟踪。斯廷解释说，他们还将在每个实例上运行chef solo，以避免将临时节点连接到chef服务器。食谱发布作业相反，烹饪书发布作业是手动触发的。它们运行与CI作业相同的测试，但是会将新的烹饪书上传到Chef服务器。使用Chef部署应用程序在工作站上，代码将被推送到GitHub上的Chef repo。这将触发一个单独的Jenkins主机，专门用于部署。然后，这个部署主机将从Chef服务器中提取相关的数据包和环境。部署从属服务器保存部署节点的SSH密钥，以及必需的gem和Chef以及凭据。 然后，斯廷解释了每个应用程序的两种部署作业类型：开发部署用于开发用于操作的非开发部署 非dev作业使用环境作业参数来定义将应用程序部署到何处，而这两个作业都采用应用程序组版本号。这些部署作业将编辑应用程序数据包和应用程序环境文件，然后将它们上载到Chef服务器，在指定环境中查找具有部署应用程序配方的所有节点，在每个节点上运行Chef客户端，并发送部署结果的电子邮件通知。单击此处查看第1部分。 特蕾西·肯尼迪解决方案架构师云蜂 作为一名解决方案架构师，Tracy的主要关注点是在持续交付云平台上接触CloudBees客户，并向他们展示如何最大限度地利用该平台。（一篇关于特雷西的"遇见蜜蜂"博客文章即将发布！）现在，在Twitter上关注她。