电子书 《DevOps实践》

[复制链接]
查看333 | 回复1 | 2019-12-3 07:58:51 | 显示全部楼层 |阅读模式

《DevOps实践》_1

《DevOps实践》_1

《DevOps实践》_2

《DevOps实践》_2

《DevOps实践》_3

《DevOps实践》_3


内容简介:

Practical DevOps
DevOps实践
端典] Joakim Verona
電子工業出顺
Publishing House of Electronics Industry
比京 BELJING

内容简介
DevOps实践》介绍了 DevOps的起源和概览,并通过一个贯穿全书的例子,从架构开始,到代码
的存储、构建、测试、部署、监控,直至流程的跟踪,推荐了许多可用的工具和可行的示范,是一本 DevOps
实践方面不可多得的参考书籍
本书面向愿意承担更大责任的开发人员和系统管理员,也很适合愿意更好地支持开发人员的运维人
员。无须任何 DevOps知识即可快速上手
Copyright o Packt Publishing 2016. First published in the English language under the title'Practical DevOps'
本书简体中文版专有出版权由 Packt Publishing授予电子工业出版社。未经许可,不得以任何方式复
制或抄袭本书的任何部分。专有出版权受法律保护
版权贸易合同登记号图字:01-2016-3999
图书在版编目(C|P)数据
DevOps实践/(瑞典)约阿基姆·维罗纳( Joakim Verona)著:高清华,马博文译
北京:电子工业出版社,2016.10
书名原文: Practical DevOps
SBN978-7-121-29812-7
1①D…Ⅱ.①约…②高…③马…Ⅲ①虚拟处理机Ⅳ①TP338
中guo版本图书馆CIP数据核字(2016)第207459号
责任编辑:张春雨
印刷:三河市双峰印刷装订有限公司
装订:三河市双峰印刷装订有限公司
出版发行:电子工业出版社
北京市海淀区万寿路173信箱邮编:100036
开本:787×980116印张:13.5字数:3024千字
版次:2016年10月第1版
印次:2016年10月第1次印刷
凡所购买电子工业出版社图书有缺损问题,请向购买书店调换。若书店售缺,请与本社发行部联系
联系及邮购电话010)88254888,882588
质量投诉请发邮件至zitsaphei.com.cn,盗版侵权举报请发邮件至dbqg(aphei.com.cn
本书咨询联系方式:010-512608889faq@phei.com.en。

译者序
什么是 DevOps?我的前同事李光磊将其译为开发自运维,他还写了篇很有意思的博客
来说明:htp/ liguanglei. name/blogs/2015/04/22 devops-chinese-name/。这个将开发和运维结
合起来的词,代表了一种文化,那就是大家共同协作。狭义上的大家,指的是开发和运维
广义上,指的是所有软件生命周期里参与的角色
“共同协作”是个富有正能量的词。感觉上,随便往哪儿一套都是正确的。那为什么
要在 DevOps里着重强调呢? DevOps到底解决了什么问题?归根结底,就是提高产品质量
思考的你,可能心里已经有千万个提高产品质量的方案从脑海里呼啸而过—代码审查
自动化测试、持续集成、代码质量管理工具、程序员鼓励师……对对对,这些方案都能在
某种程度上解决一些层次的问题。但是,产品质量的根源在哪儿呢?在于人。如果开发者
对自己要做的事情不负责,甚至压根儿不知道后果,怎么能指望这样的人能够生产出来高
的代码呢?举个例子:作为开发者,我知道自己写的代码会由测试部门来进一步测试
在有进度压力的时候,我就会更倾向于去想:“那就先这么凑合着吧,反正有问题QA们会
说的”。如果我不知道部署和维护产品是怎么一回事,我就不会主动地在产品里写上日志的
代码。对于运维人员来说,由于处于软件生命周期的下游,相信对类似的场景感触更甚。
DevOps能够做到的事,就是让人有这个意识:需要对产品的质量负责。 DevOps能够提供
一个平台或机制,让我能够从中找到所需的资源
共同协作”也是个虚无缥缈的词。它应该如何落地呢?这就是本书想要给读者们带
来的内容。在实践上,从架构开始,到代码的存储、构建、测试、部署、监控,直至流程
跟踪,本书推荐了许多可用的工具和练习,确实无愧于《 DevOps实践》之名。细读全书
可以对其有一个全局的概览并充实自己的 DevOps工具箱;而在实际场景中再查阅本书
将其当作一本各种技术的快速参考手册也不失为明智之举。本书的许多实例通过 Docker启
动,在紧随潮流技术的同时也简化了练习步骤,值得花些时间试试。在企业里,使用自动
化和持续交付来提高代码部署频率、降低代码上线间隔。这样的指标是比较容易统计的
在让管理人员满意的同时,也能减少开发和运维的痛苦。只有让各角色都真切地感受到实

vops实践
惠,大家才会更加愿意从心底接受并积极参与到这一过程中
共同协作”是个看上去很美的词。为什么大家还不赶紧拥抱它?因为它的成本可能
还挺高的。大型企业在管理上,通常权责分明,从而导致每个角色的成员都不愿意轻易踏
足其他领域;流程烦琐,导致一个小小的改进也需要漫长的批复;.安.全.性要求高,引发各
种违规,进一步导致没有和其他人分享的意愿;员工操作权限管理精密,上不了网、下不
了包、开不了虚拟机……这些问题,虽然不至于疾在骨髓,但起码也在肠胃了。而且,自
动化测试、部署流水线等都需要比较高的成本。在看见收益和认清自己之前,可能大多数
人也会像蔡桓公那样默认拒绝吧:“医之好治不病以为功”。成本最低的时候,可能就是开
始写第一行产品代码的时候。话虽如此,任何时候都是实现 DevOps的最佳时机,因为随
企业的扩大和代码库的膨胀,成本一定是越来越高的。另外,完全地追求技术上的卓越而
忽视成本也不是 DevOps的推荐做法。读者们在阅读时,也会看到 DevOps在一些状况下采
取的权衡方案
你希望在一个大家敞开心胸、相互拥抱的环境里共同协作以打造最好的产品,还是守
着自己的一亩三分地,与人争辩这是谁的责任,抱怨人们冷漠的同时拒绝其他人的“与你
无关”的要求?从本书开始,应用自己获得的知识,并尝试改造这个世界吧!

关于作者
Joakim Verona是一位擅长持续交付和 DevOps的咨询师。自194年以来,在系统开
发的所有方面他都曾工作过。他积极地在诸如web系统、多媒体系统和软硬件混合系统等
复杂的多层系统上做出了领导实践者的贡献。自2004年以来,他广泛的技能兴趣把他导向
了新兴的 DevOps领域
akim在林雪平理工学院完成了计算机科学的硕士学位。他也曾作为咨询师工作在各
种各样的工业领域中,例如银行和财务、电信、工程、印刷和排版,还有游戏开发。他还
对敏捷领域感兴趣,是一位 Scrum认证的敏捷教练、 Scrum产品负责人并拥有Java认证
我想要谢谢我的妻子, Marie,在写这本书的时候她就是灵感的源泉。我也想谢
谢过去数年曾经一起工作过的所有人和公司,让我可以工作在我喜欢的事情上


#############################################


回复

使用道具 举报

wutiwl | 2020-1-30 00:36:30 | 显示全部楼层
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则