书评：DevOps for Developers-InfoQ

《DevOps for Developers》是去年出版的，从书名可以看出作者希望能够帮助开发工程师理解 DevOps 运动，以及作为开发工程师 DevOps 意味着什么。DevOps 已经推动到目前为止系统管理员厌倦通过“翻墙”来获取软件，并且不得不花费很长的时间，以图确保软件能够在已经稳定、可靠的生产环境中运行。但另一方面，在业务的压力下，为了不断发布新功能而不得不重复各种手工操作的状况也让一些开发人员感到不快，除非业务方能够理解IT 人员在支持业务需要方面是平等的合作伙伴，就像“凤凰项目”描述的那样。（The Phoenix Project：一本关于IT，DevOps 的书籍）

因此，这本书期望填补DevOps 在这一方面的空缺。当然，作者在书中很早就澄清了他很宽泛的使用了“开发人员”这个词，包括程序员、质量保障人员和那些认可“基础设施即代码”的系统管理员。接下来，作者在书中从ALM（资产负债管理（Asset-Liability Management/Asset and Liability Management，简称ALM）的视角相对全面的介绍了DevOps。事实上，这本书也涵盖了通过对一些样例解析涵扩了从敏捷开发到持续发布，包括一些稍微偏离主题的内容，比如规范示例。这些概念都很好地联系在一起，但是对于一本小书来讲，内容的宽泛必然会影响其深度，降低其吸引力，尤其是对那些已经熟悉敏捷和DevOps 概念的人。

这本书以很有趣的方式让我们将DevOps 聚焦在三个视角: 度量观、流程观、技术观，来对比在DevOps 社区里面流行甚广的 CAMS 观点。特别是因为流程观可以降低和削弱文化、自动化、度量、分享的方法，然而，它将很容易的成为影响组织进程的一种严重阻力。

标准和度量视角涵盖了在整个开发过程中需要质量保证团队和测试团队的必要性，这也是开发和运维所有团队都需要靠近并面对的目标。作为重要的观点，这一部分可以更深入探讨一些 DevOps 的具体的环节，比如持续度量（监控）程序的性能和稳定性，在开发的迭代中集成运维团队的反馈以及在开发团队和运维团队中共享监控的任务和访问。

过程（流程）视角阐述了开发团队和运维团队深入合作的必要性以及在发布流程和基础设施管理代码环节上两者需要共同承担责任的必要性。作者在其中的一章里面推荐“使用看板作为DevOps 的流程推动方式”。在另一章中作者讨论了DevOps 的概念缺陷和道德风险，作为一本入门的书来讲，这多少有些偏离主题。特别是在针对不同背景和目标的人能保持经常合作、共享知识的同时还能够完成他们的核心工作职责上，缺乏一些极具可操作性的建议。

最后，对技术视角的阐述占了本书最大的比例，分为这样几个部分：一章关于持续发布（作者的定义是“自动化发布”），一章关于基础设施即代码（包括多个代码样例，多张 Puppet 和 Vagrant 的插图）和一章通过样例来阐释的规范。这一部分的实践方法是很受欢迎的，但是实例化需求这一章最好是丢掉，取而代之以对持续发布做更加全面深入的解释。

总的来讲，这本书作为DevOps 的入门书籍来讲，为敏捷开发的同学提供了不错的信息和参考。但是，书中各处各种具体观点的讨论深浅不一，在理论和实践之间缺乏必要的平衡性，所以，它并不适合那些寻找DevOps 现场指导书籍的人。最后，给出版商的一个负面的建议是最好在出版前能够多几个回合的校对。

关于作者：

Michael Hüttermann是一名开发工程师、交付工程师、敏捷以及 DevOps 专家，帮助项目以提升软件交付过程。他曾是甲骨文的 Java 冠军，获得 SCJA，SCJP，SCJD，SCWCD 认证，是 JCP 和敏捷联盟的一员，是 java.net JUGS 社区的领导人和 Cologne Java 用户组创始人。他参加了在芝加哥举行“敏捷 2009”主题会议，并在这个顶级的会议上发表了题目为《敏捷工具》的主题演讲。他写了三本书：“Agile Java-Entwicklung in der Praxis”（德语，O’Reilly 出版，2007 年），“Fragile Agile”（Hanser，2010 年出版）和“Agile ALM”（Manning，2011 年出版）