编辑推荐

　　从本书中将会学到

　　√ 理解DevOps和持续交付的本质并看到DevOps如何支持敏捷流程

　　√ 了解系统如何相互匹配并组成一个更大的整体

　　√ 创建并熟悉让DevOps更有效率的工具

　　√ 用DevOps的思想设计一个适合持续部署的系统

　　√ 用诸如Git、Gerrit和GitLab等不同方式高效地存储和管理代码

　　√ 配置一个构建CRUD应用样例的任务

　　√ 通过Jenkins和Selenium使用自动化回归测试来测试代码

　　√ 使用诸如Puppet、Ansible、PalletOps、Chef和Vagrant等工具部署代码

　　√ 使用Nagios、Munin和Graphite监控代码健康

　　√ 探索Trac的工作方式—— 一个用于问题跟踪的工具

内容简介

　　《DevOps 实践》介绍了DevOps 的起源和概览，并通过一个贯穿全书的例子，从架构开始，到代码的存储、构建、测试、部署、监控，直至流程的跟踪，推荐了许多可用的工具和可行的示范，是一本DevOps实践方面不可多得的参考书籍。

　　《DevOps 实践》面向愿意承担更大责任的开发人员和系统管理员，也很适合愿意更好地支持开发人员的运维人员。无须任何DevOps 知识即可快速上手！

作者简介

Joakim Verona是一位擅长持续交付和DevOps的咨询师。自1994年以来，在系统开发的所有方面他都曾工作过。他积极地在诸如web系统、多媒体系统和软硬件混合系统等复杂的多层系统上做出了领导实践者的贡献。自2004年以来，他广泛的技能兴趣把他导向了新兴的DevOps领域。

Joakim在林雪平理工学院完成了计算机科学的硕士学位。他也曾作为咨询师工作在各种各样的工业领域上，例如银行和财务、电信、工程、印刷和排版，还有游戏开发。他也对敏捷领域感兴趣，是一位Scrum认证的敏捷教练、Scrum产品负责人并拥有Java认证。

【译者介绍】

高清华：悦跑圈资深研发工程师。工作十多年以来，在简洁代码、自动化测试、持续集成、DevOps等方面都有着丰富的经验。曾在ThoughtWorks任职多年，从事敏捷软件开发、DevOps咨询等工作。

马博文，ThoughtWorks Senior Consultant，Senior DevOps，西安DevOps Meetup发起人。AWS Certified Solution Architect/Certified Developer。《Scala Cookbook》译者。熟悉Web/Ruby/Java/Scala开发，目前专注DevOps，持续交付，容器技术，微服务，AWS等。

目录

前言 XIII

1 DevOps 和持续交付简介 1

DevOps 简介 1

多快才算快？ 3

敏捷之轮 4

敏捷不只是形式 5

DevOps 和ITIL（信息技术基础架构库） 7

总结 8

2 洞察全局 9

DevOps 流程和持续交付——概览 9

开发人员 10

版本控制系统 12

构建服务器 13

工件库 13

包管理器 13

测试环境 14

预发布/生产 15

发布管理 15

Scrum、看板和交付流水线 16

圆满结束——一个完整的例子 17

识别瓶颈 18

总结 18

3 DevOps 如何影响架构 19

介绍软件架构 19

单块系统场景 20

架构经验法则 21

关注点分离 21

内聚原则 21

耦合 22

回到单块系统场景 22

一个真实例子 22

三层系统 23

表示层 23

业务层 24

数据层 24

处理数据库迁移 24

滚动升级 25

Liquibase 的Hello world 26

变更记录文件 27

pom.xml 文件 27

手动安装 29

微服务 30

小插曲——康威定律 31

如何保持服务接口向上兼容 32

微服务和数据层 33

DevOps、架构和弹性 33

总结 34

4 一切皆代码 35

源代码控制的必要性 35

源代码管理历史 36

角色和代码 37

哪一个源代码管理系统？ 38

源代码管理系统迁移之言 39

选择分支策略 39

分支问题域 41

工件版本命名 42

选择一个客户端 43

创建一个基本的Git 服务器 44

共享认证 45

托管Git 服务器 45

大的二进制文件 46

尝试不同的Git 服务器实现 47

中场休息，插播Docker 48

Gerrit 49

安装git-review 包 49

历史修正主义的价值 50

拉请求模型 52

GitLab 52

总结 54

5 构建代码 55

我们为什么要构建代码 55

构建系统的各个方面 56

Jenkins 构建服务器 57

管理构建依赖 60

最终工件 61

用FPM 取巧 62

持续集成 63

持续交付 64

Jenkins 插件 64

托管服务器 66

构建从机 66

主机上的软件 67

触发器 68

任务链和构建流水线 68

Jenkins 文件系统结构概览 69

构建服务器和基础设施即代码 70

按依赖顺序构建 70

构建阶段 71

可选的构建服务器 72

校验质量指标 72

构建状态可视化 73

严肃对待构建错误 74

健壮性 74

总结 75

6 测试代码 77

人工测试 77

自动化测试的优缺点 78

单元测试 80

一般的JUnit 和特殊的JUnit 81

一个JUnit 的例子 82

Mocking 82

测试覆盖率 83

自动化集成测试 84

在自动化测试中使用Docker 84

Arquillian 85

性能测试 85

自动化接受测试 86

自动化GUI 测试 88

在Jenkins 中集成Selenium 测试 89

JavaScript 测试 90

测试后端集成点 91

测试驱动开发 93

REPL（交互式命令行）驱动开发 93

一个完整的自动化测试场景 94

人工测试web 应用 94

运行自动化测试 97

查找缺陷 98

测试巡礼 98

用Docker 处理棘手的依赖 102

总结 103

7 部署代码 105

为什么有这么多的部署系统 105

配置基础操作系统 106

描述集群 107

为系统交付包 107

虚拟化栈 109

在客户端执行代码 111

有关练习的注意事项 111

Puppet 服务器和Puppet 代理 112

Ansible 113

PalletOps 117

用Chef 做部署 117

用SaltStack 做部署 118

从执行的模型来比较Salt、Ansible、Puppet 和PalletOps 120

Vagrant 121

用Docker 做部署 123

对比表 124

云计算解决方案 124

AWS 125

Azure 126

总结 126

8 监控代码 127

Nagios 127

Munin 134

Ganglia 138

Graphite 142

日志处理 144

客户端日志类库 145

ELK 147

总结 149

9 问题跟踪 151

用问题跟踪器做什么？ 151

工作流和问题的一些例子 152

我们需要从问题跟踪器里得到什么？ 154

问题跟踪器激增所带来的问题 157

所有的跟踪器 158

Bugzilla 158

Trac 164

Redmine 172

GitLab 问题跟踪器 178

Jira 181

总结 183

10 物联网和DevOps 185

IoT 和DevOps 简介 185

从市场的角度看物联网的未来 188

机器到机器的通信 190

物联网的部署影响软件架构 191

物联网部署的安全性 191

好啦，但是DevOps 和物联网有什么关系？ 192

DevOps 的物联网设备动手实验室 193

总结 199

前言/序言

　　DevOps 领域在近年来变得流行而普遍。它是那么的流行，以至于很容易忘记在2008年以前，当Patrick Debois 组织起第一个DevOps 之日大会时，几乎没人曾经听说过该词。由开发（developers）和运维（operations）组成的DevOps 这个词，到底意味着什么？

　　为什么它能造成如此巨大的狂热？

　　本书的任务就是回答这个看起来很简单的问题。

　　简短的答案就是：DevOps 旨在将不同的社区，比如开发和运维社区，联合起来变成一个更有效率的整体。

　　这也反映在本书中。它探索了许多在DevOps 工作中有用的工具，还有那些更加凝聚人们的工具，这些工具比起那些在人之间划清边界的工具来说更令人喜爱。我们用来进行软件开发的流程也是工具，所以将DevOsp 相关的不同敏捷流派的各个方面包含进来也是很自然的事。

　　本书也希望做到像标题说的那样，注重实战。让我们在DevOps 之路上开始旅程吧！

　　本书主要内容

　　第1 章，DevOps 和持续交付简介，涉及了DevOps 的背景，并介绍它是怎样融入到敏捷开发的广袤世界的。

　　第2 章，洞察全局，它会帮助你了解DevOps 使用的多个系统如何协同工作，组成一个大整体。

　　第3 章，DevOps 如何影响架构，描述了软件架构的各个方面，以及当我们以DevOps的视角工作时它对我们的意义。

　　第4 章，一切皆代码，解释了如何实现一切皆代码。而且，你需要一个地方来存储代码，这个地方就是组织里的源代码管理系统。

　　第5 章，构建代码，解释了为何需要系统来构建代码，介绍了这些系统。

　　第6 章，测试代码，展示了如果需要及早发布或者经常性发布代码，我们就得对代码的质量有信心。因此我们需要自动化回归测试。

　　第7 章，部署代码，展示了当完成了代码的构建和测试，你需要将其部署到服务器上，

　　这样客户就能使用新部署的特性了。

　　第8 章，监控代码，涵盖了代码如何通过选择的部署方案来安全地部署到服务器上。

　　你需要监护着它以使其正常工作。

　　第9 章，问题跟踪，介绍了处理组织内开发流程的系统，例如问题跟踪软件。在实现敏捷流程时，这样的系统是很重要的帮手。

　　第10 章，物联网和DevOps，描述了DevOps 如何在物联网的新兴领域帮助我们。

　　本书的使用要求

　　本书包含了许多实用例子。为了融会贯通这些例子，你需要一台机器，最好是基于GNU/Linux 的操作系统，例如Fedora。

　　本书的读者

　　本书面向那些想要承担更大责任，并了解基础设施如何做到构建现代企业的开发者。

　　本书也面向那些想要更好地支持开发者的运维人员。自动化测试的技术人员也是本书的目标受众。

　　本书主要是包含了许多实例的技术文档，适合那些想要学习实现具体工作代码的人员。

　　尽管如此，前两章的实践性并不强。它们交代了有助于了解其余章节的背景和概览。

　　约定

　　在本书中，你将会发现不同的信息类型使用不同的文本样式来区别。这里列出了一些范例和解释：

　　文本中的代码、数据库表名、文件夹名、文件名、文件扩展名、路径、伪URL、用户输入和Twitter 标签以下列形式展示：“在你的本地安装git-review”。

　　代码段如下所示：

　　private int positiveValue;

　　void setPositiveValue(int x){

　　this.positiveValue=x;

　　}

　　int getPositiveValue(){

　　return positiveValue;

　　}

　　命令行的输入输出如下所示：

　　docker run -d -p 4444:4444 --name selenium-hub selenium/hub

　　新术语和关键词粗体显示。你在屏幕上看到的词，例如在菜单或者是对话框里，在文本中看起来像是这样：“我们可以通过修改按钮改变状态。”

　　警告或是注意事项像这样展示。

　　要诀和技巧是这样的。

　　勘误表

　　虽然我们已经尽力谨慎地确保内容的准确性，但错误仍然存在。如果你发现了书中的错误，包括正文和代码中的错误，请告诉我们，我们会非常感激。这样，你不仅帮助了其他读者，也帮助我们改进后续的出版。如发现任何勘误，可以在博文视点网站相应图书的页面提交勘误信息。一旦你找到的错误被证实，你提交的信息就会被接受，我们的网站也会发布这些勘误信息。你可以随时浏览图书页面，查看已发布的勘误信息。

　　译者序

　　什么是DevOps？我的前同事李光磊将其译为开发自运维，他还写了篇很有意思的博客来说明：http://liguanglei.name/blogs/2015/04/22/devops-chinese-name/。这个将开发和运维结合起来的词，代表了一种文化，那就是大家共同协作。狭义上的大家，指的是开发和运维，广义上，指的是所有软件生命周期里参与的角色。

　　“共同协作”是个富有正能量的词。感觉上，随便往哪儿一套都是正确的。那为什么要在DevOps 里着重强调呢？DevOps 到底解决了什么问题？归根结底，就是提高产品质量。爱思考的你，可能心里已经有千万个提高产品质量的方案从脑海里呼啸而过——代码审查、自动化测试、持续集成、代码质量管理工具、程序员鼓励师……对对对，这些方案都能在某种程度上解决一些层次的问题。但是，产品质量的根源在哪儿呢？在于人。如果开发者对自己要做的事情不负责，甚至压根儿不知道后果，怎么能指望这样的人能够生产出来高质量的代码呢？举个例子：作为开发者，我知道自己写的代码会由测试部门来进一步测试，在有进度压力的时候，我就会更倾向于去想：“那就先这么凑合着吧，反正有问题QA 们会说的”。如果我不知道部署和维护产品是怎么一回事，我就不会主动地在产品里写上日志的代码。对于运维人员来说，由于处于软件生命周期的下游，相信对类似的场景感触更甚。DevOps 能够做到的事，就是让人有这个意识：需要对产品的质量负责。DevOps 能够提供一个平台或机制，让我能够从中找到所需的资源。

　　“共同协作”也是个虚无缥缈的词。它应该如何落地呢？这就是本书想要给读者们带来的内容。在实践上，从架构开始，到代码的存储、构建、测试、部署、监控，直至流程的跟踪，本书推荐了许多可用的工具和练习，确实无愧于《DevOps 实践》之名。细读全书可以对其有一个全局的概览并充实自己的DevOps 工具箱；而在实际场景中再查阅本书，将其当作一本各种技术的快速参考手册也不失为明智之举。本书的许多实例通过Docker 启动，在紧随潮流技术的同时也简化了练习步骤，值得花些时间试试。在企业里，使用自动化和持续交付来提高代码部署频率、降低代码上线间隔。这样的指标是比较容易统计的，在让管理人员满意的同时，也能减少开发和运维的痛苦。只有让各角色都真切地感受到实惠，大家才会更加愿意从心底接受并积极参与到这一过程中。

　　“共同协作”是个看上去很美的词。为什么大家还不赶紧拥抱它？因为它的成本可能还挺高的。大型企业在管理上，通常权责分明，从而导致每个角色的成员都不愿意轻易踏足其他领域；流程烦琐，导致一个小小的改进也需要漫长的批复；安全性要求高，引发各种违规，进一步导致没有和其他人分享的意愿；员工操作权限管理精密，上不了网、下不了包、开不了虚拟机……这些问题，虽然不至于疾在骨髓，但起码也在肠胃了。而且，自动化测试、部署流水线等都需要比较高的成本。在看见收益和认清自己之前，可能大多数人也会像蔡桓公那样默认拒绝吧：“医之好治不病以为功”。成本最低的时候，可能就是开始写第一行产品代码的时候。话虽如此，任何时候都是实现DevOps 的最佳时机，因为随企业的扩大和代码库的膨胀，成本一定是越来越高的。另外，完全地追求技术上的卓越而忽视成本也不是DevOps 的推荐做法。读者们在阅读时，也会看到DevOps 在一些状况下采取的权衡方案。

　　你希望在一个大家敞开心胸、相互拥抱的环境里共同协作以打造最好的产品，还是守着自己的一亩三分地，与人争辩这是谁的责任，抱怨人们冷漠的同时拒绝其他人的“与你无关”的要求？从本书开始，应用自己获得的知识，并尝试改造这个世界吧！

继续丰富书架收藏

书写的不错，提供的很多的知识点！

很不错，已经开始准备用了，下次还会购买

指着它脱离人肉运维之痛，哈哈哈。一口气25本书，还是很爽的，重要的是学到东西，豆瓣上评价不错，不说了拿发票去报销了。

好的东西不错的还行就

对于了解devops还是有帮助的 比较薄

学无止境，必须紧跟技术的发展，不然就淘汰。

买太多东西，总是要逐一晒单。东西不错，送货快，唯一有问题的是，京东的商品价格总是变动。

Google运维大牛的经验总结，做运维必读的书