书评：《使用 Chef 框架进行测试驱动基础设施开发第 2 版》

在《使用 Chef 框架进行测试驱动基础设施开发第 2 版》一书的第 1 章，Stephen Nelson-Smith 谈论了测试驱动基础设施开发的一些宗旨。他特别列举了两条最基本的观点：

1. 基础设施能够、也应该被视为代码
2. 基础设施开发者也应该坚持其他方面的软件开发者所遵循的相同专业性原理。

随后，他对这两点进行了深入讲解。

在 2006 年左右，像 Amazon EC2 这样的实用计算平台，以及像 Ruby on Rails 这样的第二代 web 框架的出现，使得即使是最小的团队也能够创建出互联网规模的应用程序。很快，Puppet 及几年后出现的 Chef 框架则实现了帮助人们管理大规模 web 基础设施的功能。Stephen 在书中是这样说的：

通过共同设计应用程序所运行的基础设施代码，我们就将运营的责任交给了开发者。这样就使系统管理员的重担得以减轻，他们可以更专注于设计和软件的生命周期，从更高的抽象角度进行思考。

在对基础设施即代码的历史进行了一番挖掘之后，Stephen 列举了基础设施即代码的一些原则，举例如下：

1. 将基础设施分解为独立的、可重用的，并且可以在网络中进行访问的服务。
2. 按照某种方式整合这些服务，使他们能够实现基础设施所需的功能。

随后他强调了采取基础设施即代码开发方式的主要风险：例如重复代码、对基础设施代码缺乏清晰的了解、不敢改动代码，或者是过于依赖理解基础设施代码的个别关键人士。

为了缓解这些风险，Stephen 认为编写基础设施代码需要和编写应用程序同等的谨慎和专业度，在编写任何代码时，都需要遵从一些必要的实践，例如对基础设施代码的模块化设计、代码共同责任人、代码复审、代码标准、重构和测试。

在介绍了这些主旨之后，Stephen 用了几个完整的章节介绍了 Ruby 和 Chef，以及通常与 Chef 一起使用的一些基本工具，例如 VirtualBox 和 Vagrant。

在第 5 章，Stephen 介绍了测试驱动和行为驱动的开发方式。

到这里，读者们应该已经对测试驱动开发基础设施代码所需的必要概念和工具有了一个基本的理解。

在第 6 章，Stephen 介绍了一个他设计的针对测试驱动基础设施的概念性框架，叫做 MASCOT。他是这样说的：

测试驱动基础设施应该有如下特征：

• 主流的
• 自动化的
• 无副作用的
• 持续集成的
• 由外及内的
• 测试优先的

在第 6 章的余下部分对这些要点分别进行了细节讨论。

第 7 章为测试驱动基础设施开发推荐了一套工具集。在这一章的开头，他再次强调了测试驱动基础设施的两条宗旨：

1. 基础设施能够、也应该被视为代码
2. 基础设施开发者也应该坚持其他方面的软件开发者所遵循的相同专业性原理。

他随后介绍了不同类型的测试方法：包括单元测试、集成测试以及验收测试，并且介绍了测试的整个工作流，以说明在每种测试方法应该应用在什么阶段。

在介绍完测试类型和测试工作流之后中，Stephen 介绍了他所推荐的工具集：

• 使用 Berkshelf 管理 cookbook 的依赖
• 使用 Vagrant 管理运行测试的虚拟机
• 使用 Test Kitchen 在多个节点和平台上运行测试
• 使用 Cucumber 和 Leibniz 进行验收测试
• 结合使用 Serverspec、Bats 和 Test Kitchen
• 使用 Minitest Handler 进行集成测试
• 使用 Chefspec 进行单元测试
• 使用静态分析和代码清理工具，例如 Foodcritic、Knife Cookbook Test、Tailor 和 Strainer

本书对以上每一条都提供了详细的上手操作指南、代码示例，并且对每种工具的优缺点都进行了一番描述。这一部分可以说是全书最实用的部分，读者可以跟随书中的讲解很快上手这些工具。在本书的最后一部分，Stephen 对如何在整个测试工作流中使用每一种工具进行了一番总结。

Stephen 也欣然地回答了关于本书的几个问题。

InfoQ：是什么动机促使你撰写了本书的第二版呢？

Stephen：本书的第一版应该算是一次投石问路，它算是一个宣言。不过我的感觉更像是听到了旷野中的哭声的施洗者约翰！我有一种很强烈的感觉，那就是我们应该对基础设施代码应用测试优先的原则和 BDD 方式，并且我想把这种观点分享给大家。就在本书第一版出版后不久，我就清楚我开始触及到了关键，整个生态系统蓬勃发展，而且每个人都开始讨论测试驱动基础设施。很显然我有必要对第一版进行更新和补充，一方面是回应读者的需求，另一方面，是因为我觉得我还有许多要写的东西！随着这个生态圈的成熟与壮大，即时同样的事情再发生一次，我也不会感到惊奇的。

InfoQ：你提到了关于测试驱动基础设施开发的两条哲学性的基础：

1. 基础设施能够、也应该被视为代码
2. 基础设施开发者也应该坚持其他方面的软件开发者所遵循的相同专业性原理。

关于这两条，你所听到的最大的反对声音是来自哪里？

Stephen：老实说，我已经很少再听到对第一条的反对声音了，因为它已经基本成为一种主流的观点了。如果偶尔出现一些不同的观点，我认为主要可以归结为以下两点。首先，有一种顾虑认为编写基础设施代码是一种浪费，尤其是在非常小规模的应用中，不如直接设置好机器就完事了。其次 ，在一些更为传统的企业环境中，IT 专家可能会对此感到排斥和不安，他们对于必须学习新的编程知识这一点可能会感到不自在。

至于第二条，我认为它已经被普遍接受了。不过有时这一观点会被解读为：专业性就意味着测试优先，而持续集成则代表了最新的科技发展水平。对于某些工程师来说，他们对自己在自动化方面已经投入的努力和成果感到骄傲，对于以上这种解读方式不一定能够接受。对于这种情形，我认为重要的是不要自以为高人一筹、显得思想非常狭隘。我的意思绝不是说必须使用基于极限编程风格的测试优先方式创建自动化系统，否则就是不专业的表现。我的意思是，我们需要认识到我们所开发的软件很可能会成为核心业务的支柱，如果没有一个良好的自动化测试机制，就不应该将应用程序部署到生产环境。我们也应该按照相同的方式来对待基础设施开发。

InfoQ：书中有这么一段话：“对基础设施代码进行完整地、可重复性的测试是不可缺少的，它也是基础设施开发者工作中的重要环节。”你在书中鼓励开发者遵循这一观点，并为他们提供了必要的入门知识。但假设如果有某个对自己要求很高的基础设施开发者目前正在工作中忙于救火，他不知道如何能够兼顾以上观点，你会对他说些什么呢？

Stephen：救火工作一直都是系统管理员生活中的一部分，从我们第一天开始工作时就知道这一点了。但有智慧的系统管理员都明白，他们需要了解的知识不仅仅是救火，还包括如何使得系统更可靠，怎样减少类似问题发生的机率等等。我相信现在已经普遍接受了这个观点，即使用类似于 Chef 这样的自动化框架创建与维护基础设施能够帮助我们实现这一目标，如果大家都能将我所提倡的原理应用于实际，那么最终我们也会减少救火的次数。我对那些工作超负荷的系统管理员们深表同情，但我想我们应该记住这句格言：“磨刀不误砍柴工”，或许你花了好几个小时都砍不倒一棵很结实的树，却又坚持自己忙于砍柴，没时间去磨刀，结果可想而知……

InfoQ**：在第 6章中，基于你的 MASCOT原则，你为 TDI**定义了一个概念框架：

测试驱动基础设施应该有如下特征：

• 主流的
• 自动化的
• 无副作用的
• 持续集成的
• 由外及内的
• 测试优先的

你觉得如今对 TDI**** 的应用已经到了怎样的水平，你对未来的发展又是怎么看的呢？

Stephen：从我对这个社区的观察情况来看，不可否认的是，人们正在扭转自己的思维，渐渐走向了正确的方向。我认为人们已经开始广泛地接受这些原则与工具，我也看到这种思维正在向整个业界开始漫延。虽然我认为它现在还算不上是主流思想，但确实正在朝这个方向前进。

关于自动化方面，我认为这方面的认识已经接近统一了。像 Test-Kitchen 这样的框架带来的好处是巨大的，而且已经有不少人开始往开源的方面发展了，包括 Chris McLimmans、我本人以及 Chef 的一些开发者已经在基础设施的持续发布 / 部署方面取得了一些进展。我们在知识共享方面已经做的不错了。

说到副作用，我认为人们已经能够敏锐地察觉即使是很小的改动所引起的链锁反应了，而且由于使用 Jenkins 或 Travis 运行测试已经越来越普遍，可以看到这对方面的察觉力也在不断提高。这方面的话题已经属于了持续集成的范畴，我们已经有丰富的工具和良好的态度，这使我们能够期望所有的基础设施开发者都能够将它们的 cookbook 进行持续集成了。我所看到的不足之处，在于对 Windows 的支持这方面还是要稍落后于 Linux，但我已经看到在这方面进行改进的趋势了，我也对此感到非常兴奋。

最后两条的成熟度是做的最差的。ChefSpec 3.0 的新功能以及 Test Kitchen 1.0 的发布的支持使单元测试与集成测试相对而言得到了提升，但至少在我看来，由外及内的验收测试，即实例化需求（Specification by Example）这方面依然没有得到足够的重视。至于测试优先这一条，我坚决相信它应该是工作流中的一部分，但了解这一点不是自然而然的，而且需要足够的纪律性去执行。更多的时候，我所看到的是人们在编写代码之后再去拼凑测试方法，而我希望看到的是相反的过程。我想人们可能需要多看一些这方面的知识传授和演示。

InfoQ**：你介绍了一种由内而外进行基础设施测试的方式，它使用 Cucumber进行验收测试，并使用 RSpec进行单元测试。你还使用了 Test-Kitchen****（配合 Ruby Gem的 Leibniz组件）进行自动化测试。你对 TDI**方面的工具是怎样评价的？在未来的两到三年之内会有怎样的进展呢？

Stephen：我认为我们已经在单元测试和集成测试方面确立了一套通用的工具集，它基于 RSpec（或者是 ChefSpec 和 ServerSpec），并由 Test-Kitchen 进行统一。我希望、并预期在未来几年内能够实现在多个节点上运行的栈级别的验收测试。Leibniz 是一种很简单的 Ruby gem，它所做的就是暴露了一组帮助方法，通过它们可以在一个给定的运行列表中运行基础设施代码，这使开发者们能够在 Gherkin 内编写有意义的示例。难点在于编写测试方法本身。另外，我认为在测试的运行操作（Orchestration）上还有些需要提高的地方，包括建立一组机器，等待某台机器可用，随后在该机器上运行测试。这方面的工作需要进行一些思考和工程学，这也是我能够预期的最能够产生创新性的地方。

关于作者

Stephen Nelson-Smith (@LordCope) 目前在 Atalanta Systems 担任首席顾问，这是一家来自欧洲的快速成长的敏捷基础设施咨询公司，它们还提供 Opscode 方面的培训和解决方案。作为渐渐显露头角的 Devops 观念方面的奠基人之一，他在实现配置管理和自动化系统方面已经有 5 年的经验，客户中包括了 Sony、英国政府和 Mercado Libre 等大机构，也包括来自发展迅速的“伦敦硅谷”（Silicon Roundabout）的一些创业公司。作为一名 UNIX 系统管理员、Ruby 和 Python 程序员、精益与敏捷的实践者，他在专业方面的热情确保了运营团队能够交付商业价值。他还是一个著名博客的作者，他现在住在英国汉普郡。他喜爱户外运动、与家庭成员共同活动，也喜欢阅读和歌剧。

查看英文原文： Book Review: Test-Driven Infrastructure with Chef - Second Edition