详情
本书从以练代学的角度讲解了IT运维的一些实用知识和相关运维工具的使用技巧，其内容有：实用SOnarqube分析静态代码，配置基于Maven的JEE Web应用，使用Jenkins和VSTS执行持续集成，安装和配置Docker，使用Check工作站汇聚Chef节点，使用Apache Jmeter执行载入测试，监控位于云上的资源等。
书名：DevOps开发运维训练营
ISBN：978-7-115-47257-1
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [印度] Mitesh Soni
译 姚 军
责任编辑 傅道坤
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © Packt Publishing 2017. First published in the English language under the title DevOps Bootcamp.
All Rights Reserved.
本书由英国Packt Publishing公司授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
DevOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
本书从以练代学的角度讲解了IT运维的一些实用知识和相关运维工具的使用技巧，总共分为8章，其内容有DevOps概念与评估框架，如何安装Jenkins持续集成服务器，如何使用开发或者QA环境的容器，云计算与配置管理，持续交付，自动化测试（功能和负载测试），使用编排技术自动化应用程序生命周期的不同方法，与特定角色相关的安全和监控。
本书适合打算学习DevOps以及打算在公司内部建设DevOps文化的IT开发人员、运营人员和管理员阅读。
Mitesh Soni是一位热心的学习者，在IT行业已有10年的经验。他拥有SCJP、SCWCD、VCP、IBM Urbancode认证，是IBM Bluemix认证专家。他热爱DevOps和云计算，对Java编程也有兴趣，觉得设计模式十分迷人。他相信“一图胜千言”。
Mitesh喜欢和孩子一起玩耍，摆弄自己的照相机，在Indroda公园拍摄照片。
他痴迷于拍照，但是并不想弄懂许多技术细节。他生活在圣雄甘地祖国的首都。
Mitesh已经在Packt出版了如下书籍：
Implementing DevOps with Microsoft Azure
DevOps for Web Developers [Video]
DevOps for Web Development
Jenkins Essentials
Learning Chef
“在我的生涯中已经投失了9 000个球，输了300场比赛，我曾经26次在队友的信任下投绝杀球不中。在我的生命中一而再、再而三地失败，而这正是我成功的原因。”
——迈克尔•乔丹
我总是衷心地感谢在我人生旅程中给予帮助的人们，但是我猜测，现在是时候真正地感谢一个人，每当我能记起的时候，他总与我同在。
最后，感谢所有教我爱自己的人们！
aniel Jonathan Valik是云服务、平台即服务、统一通信与协作技术的行业专家。他还精通其他领域，如IOT、DevOps、自动化和软件流水线管理解决方案、微服务、容器化、虚拟化、云原生应用、人工智能、托管PBX和云电话、WebRTC、统一消息传输、联络中心解决方案和通信驱动业务流程设计。
Daniel曾经担当过多个不同门类的工作，如产品营销、产品管理、项目管理、行业倡导者和策略顾问，并在不同地区生活和工作过，如欧洲、东南亚和美国。他有更改管理和战略管理的双硕士学位，曾编著多本与云服务、统一通信、DevOps、云服务与迁移、AI和游戏开发相关的技术与业务图书。
谨以本书献给在我的生命中带来希望之光的人们。我想把本书献给Shreyansh（Shreyu——我姐姐Jigisha的儿子），他向我展示了天真和微笑的力量；Vinay Kher，感谢他的祝福；感谢我的父母，他们总是默默地为我祷告；感谢Simba（Priyanka Agashe），他总是支持和鼓励我，让我相信自己。
DevOps不是一种工具、技术、过程或者框架，而是一种文化。文化是特定于组织的，并随着人、过程和工具的组合而发展，以持续的创新带来持续的改善。
一次又一次地重复相同的工作，其代价远高于改变。改变不是对组织文化的威胁，运用破坏性的创新只会改善文化。改善就是向正确的方向改变，从错误或者经验中学习，不断向正确的方向改变，就能达到完美。开个玩笑：“改变是不可避免的，即使对当今的自动售货机都是如此。”
DevOps不是到达一个目的地、享受美景，然后结束旅程。它是一个永远不会结束的持续改善的过程，在这个过程中，我们创新和规划，在旅程或者过程的享受中到达相同的目的地。每次改善和创新的过程可能不同，但是目标从未改变！这个目标就是以高成本效益的方式，最大限度地利用资源，更快地进入市场，获得最高的客户满意度。
本书不仅强调技术，还重视DevOps文化应该包含的不同实践。DevOps还处于初级阶段。作为一个组织，在改进和创新的道路上，决定不做什么是很重要的。决定不进行重复性的手工作业也很重要。在本书中，我们将介绍DevOps的所有关键实践，如持续集成、使用容器的资源配给和云计算——IaaS（Amazon EC2和Microsoft Azure虚拟机）和PaaS（Azure App Service或 Azure Web Apps 和 Amazon Elastic Beanstalk）、持续交付、持续测试和持续部署；如何在云环境中自动化构建集成和配给资源；在Amazon Elastic Beanstalk、 Microsoft Azure Web Apps/App Service Environments中部署Web应用；AWS和Microsot Azure Public Cloud中的应用监控；以及在VSTS和Apache JMeter中的负载测试。
我们的主要目标是管理应用程序生命期。通过自动化重复的手工过程，我们可以将应用程序生命期管理标准化，并避免错误。我们还在Jenkins和VSTS中的不同环境提供基于批准的应用部署，提供对应用生命期管理的治理，上述两个系统中都有插件或者现成的相关功能。
为了持续集成和持续发行（持续交付和持续部署），我们已经使用Jenkins和Vistual Studio Team Services（VSTS）。端到端自动化编排和基于批准的工作流由Jenkins和VSTS管理。
没有改变的思维，就不可能有进步，为了改变任何东西，我们必须将改变形象化。在本书中，我们试图聚焦于运用人（开发团队、QA团队、运营团队、云团队、构建工程师、基础设施团队等）、过程（持续集成、自动化资源配给、持续交付、持续测试、持续部署、持续监控、持续改进和持续创新）以及工具（开源和Microsoft技术栈），来一次DevOps世界的文化之旅。
用开源工具和Micrsoft技术栈展现过程或者实践的主要原因是培养一种感觉：DevOps不关乎工具，而关乎思维方式！我们可以用任何自动化工具执行几乎相同的运营操作。
第1章，“DevOps概念与评估框架”，涵盖了如何从更高层次上快速理解DevOps、如何准备改变文化的相关细节。这一章讨论了DevOps的目标以及需要从管理层得到的支持，为DevOps的概念打下基础。
第2章，“持续集成”，说明如何安装Jenkins持续集成服务器，执行与编译、单元测试执行、代码分析和创建打包文件的相关任务。这一章还介绍使用Microsoft技术栈进行的持续执行，目标是尽可能获得更多的持续集成的相关信息，因为它是其余自动化手段的基础。
第3章，“容器”，说明如何使用开发或者QA环境的容器，以更好地利用资源。这一章包含了创建Tomcat容器的方法，以及在其中部署应用程序的细节。
第4章，“云计算与配置管理”，聚焦于在云引用部署环境的创建和配置。这一章将介绍基础设施即服务的使用，以及如何使用配置管理工具Chef创建一个平台，以便在本书的余下章节中自动化部署应用程序。
第5章，“持续交付”，说明在平台以不同方式准备好时，如何部署Web应用程序。这涉及AWS和Micrsoft Azure等平台， AWS Elastic Beanstakl和Microsft Azure App Services等IaaS及PaaS服务。我们还将介绍基于脚本的部署和Jenkins的基于插件部署。
第6章，“自动测试（功能和负载测试）”，说明了在非生产环境中部署应用之后可以进行的各类测试，介绍了利用自动化测试技术改进应用质量的方法，如使用开源工具进行的功能测试和负载测试。
第7章，“编排——端到端自动化”，包含了使用编排技术自动化应用程序生命期管理的不同方法。构建流水线用于编排持续集成、持续交付和持续测试。构建和发行定义以某种方式配置，组成一个流水线，实现具有相应基于批准机制的端到端自动化。
第8章，“安全与监控”，讨论的安全是以仅有特定利益相关方的角色为基础的，所以这些角色可以管理配置和构建。我们将研究自动化生命期管理、监控和根据成败通知结果、使利益相关方采取必要修复措施的各种工具。
本书假定读者至少熟悉Java编程语言。如果想要更深入地探索本书的内容，具备核心Java和JEE的知识是必不可少的。对Web应用在Tomcat等应用服务器上部署的深入理解将能帮助你更快地理解流程。但是，我们将提供简单的概述。由于应用开发生命期涵盖许多工具，对代码存储库和Eclipse等IDE工具、Ant及Maven等构建工具的一些了解也是必要的。
代码分析工具的知识将使你的配置和集成工作更得心应手；但是，这对于执行本书中的练习来说并不是必要的。大部分配置步骤都有清晰的步骤说明，并提供直观的屏幕截图。
你将经历熟悉Jenkins、VSTS、Microsoft Azure Web Apps和AWS Elastic Benstalk所需的步骤。对于Microsoft Azure，可以使用1个月的试用版本。VSTS也有一个包含某些限制的试用账户。AWS也有特定限制条件的一年试用期。
本书的目标读者是希望快速学习和在组织中建设DevOps文化的IT开发人员、运营人员和管理员。本书特别适合开发人员、技术领导、测试人员和运营专业人士，这些目标读者希望引入容器、Chef配置管理工具、Microsoft Azure PaaS、应用服务和SQL数据库，以托管应用程序。读者知道开发和运营团队所面对的问题，因为他们是应用生命期管理过程中的利益相关方。引入Jenkins Automation Server、Microsoft Azure PaaS和VSTS，是为了理解它们对持续集成、自动化测试用例执行和持续开发的重要贡献，这些都是高效应用程序生命期管理的要素。
以往在持续集成、云计算、持续交付和持续部署上有一定经验是很有用的。你可能是一位新手，也可能对Jenkins等持续集成工具有经验。本书涵盖了持续集成、云计算、持续交付和一个基于Spring的Java样板应用程序的持续部署，主要目标是了解端到端自动化，在开放源码和Microsoft技术栈上实施，并根据从本书中得到的知识进一步扩展。
读者可以从http://www.epubit.com.cn/book/details/7709下载示例代码文件。
一旦建立了创新的文化，即使那些并非科学家或者工程师的人——诗人、演员、记者——也能以团体的形式，接受科学文化的意义。他们信奉创新文化的概念。他们以促进这种文化的方式投票。他们不会反对科学，也不会反对技术。
——Neil deGrasse Tyson
在本章中，我们讨论如何快速地从更高的层面理解DevOps，介绍准备改变文化的最佳实践。我们将讨论DevOps的目标以及从组织管理层得到支持的方法，为DevOps的概念打下基础。我们将试着从根本上介绍使应用程序生命期管理简单、高效的DevOps实践。
DevOps不是一种框架、工具或者技术，理解这一点非常重要。它更多的是与组织的文化有关。DevOps还是人们在组织中使用预先定义的过程、利用自动化工具，使日常工作更加高效、手工工作更少的一种方法。
为了理解DevOps的重要性，我们在本章中将包含如下主题：
DevOps的必要性；
如何发展DevOps文化；
PPT（人、过程和技术）的重要性；
为什么DevOps不全和工具有关；
DevOps评估问题。
Harriet Tubman有一段名言，可以在http://harriettubmanbiography.com上找到：
每个伟大的梦想都源于梦想家。永远铭记，你拥有的力量、耐心和热情，可以令你摘星揽月、改变世界。
改变是生命的法则，也适用于组织机构。如果任何组织或者个人只盯着过去或者现有的模式、文化或实践，他们就肯定会错失未来的最佳实践。在动态的IT世界中，我们必须赶上技术革新的步伐。
我们可以参考乔治•萧伯纳的名言：
不改变就不可能进步，无法改变自己的想法，就不能改变任何东西。
现在，我们关注的是应用程序生命期管理方法的改变。重要的是，我们是否真的需要这种改变？我们是否真的需要经历改变的痛苦？
答案是肯定的。
人们可能会说，这种业务或者文化的改变不能是强制性的。
同意。
让我们在图1-1的帮助下，理解现代世界中组织在应用程序生命期管理中面对的痛点。
图1-1
考虑到业务中不断变化的模式和竞争环境，改善应用程序生命期管理是当务之急。
在现代，有什么因素能够帮助我们改善应用程序生命期管理？
是的，云计算改变了游戏规则，为许多开创性的解决方案和创新打开了大门。让我们来理解云计算的真正意义，以及DevOps和自动化等术语在企业中所起的重要作用。
从计算革命来看，云计算是下一个合乎逻辑的步骤。从传统数据中心和虚拟化，到混合环境、私有云、公共云和混合云服务，云计算是向云消费者按需提供多租户或者专用计算资源（如计算、存储和网络）的计算类型。云计算有多种不同风格，包括不同的云部署模型和云服务模型。最重要的是其定价模型——现收现付。
云部署模型是云资源部署的方式。
1）私有云：私有云由防火墙后专门用于特定组织的场内云资源组成。
2）公共云：公共云由可用于所有组织及个人的云资源组成。
3）混合云：混合云由可用于一组有类似兴趣或者类似需求类型的组织的云资源组成。
4）社区云：社区云由组合两种或者更多部署模型的云资源组成。
云服务模型描述了向各类客户（个人、小型组织、大型企业）提供云资源的方式。
云服务模型包括：云客户或者最终用户可以访问和控制虚拟机的纯基础设施——基础设施即服务（IaaS）；提供运行时服务，云服务提供者提供和管理运行应用所需的所有软件安装及配置的平台——平台即服务（PaaS）；云服务提供者提供整个应用程序，负责基础设施和平台的软件即服务（SaaS）。
近几年涌现了许多服务模型，但是IaaS、PaaS和SaaS是基于美国国家标准与技术学会（NIST）的定义，如图1-2所示。
云计算有一些重要的特性，如多租户，类似于电力或者煤气的现收现付模式，提供更高计算、存储和网络资源利用率的按需自助服务和资源池化，用于根据需要自动扩展和收缩资源的快速伸缩，以及用于计费的可度量服务。
多年以来，不同云部署模型的使用根据用例而改变。最初，公共云用于非关键应用，而私有云用于关注安全性的关键应用。混合云和公共云的使用随着时间的推移以及对云服务提供商所提供服务的经验及信心而发展。同样地，不同云服务模型的使用也根据用例和灵活性而有所不同。IaaS在早期最受欢迎，但是PaaS则凭借其成熟度和自动伸缩、支持多语言和支持端到端应用程序生命期管理工具的易用性而后来居上。
图1-2
DevOps与发展开发和IT运营团队之间的协作，以比现有方式更高效地管理应用程序生命期的组织文化、过程和技术有关（见图1-3）。我们在工作中往往倾向于根据模式，从类似的问题或者挑战中找出可重用解决方案。
图1-3
多年之后，成功与失败的试验、最佳实践、自动化脚本、配置管理工具和方法论已经成为DevOps文化中不可分割的一部分。
DevOps有助于定义设计方法、开发方法、测试方法、安装方法、环境管理方法、配置管理方法、应用部署方法、反馈收集方法、代码改善方法和创新方法。
下面是开展DevOps实践的一些明显好处。
DevOps是一系列创新，以高效的方法将开发与运营团队整合在一起，这些方法包括持续构建集成、持续测试、云资源配给、持续交付、持续部署、持续监控、持续反馈、持续改善和持续创新，按照敏捷方法论的要求，更快地交付应用程序。文化的发展不是一夜之间就能完成的，需要很长的时间。但是，对于DevOps究竟是什么仍存在概念上的混淆，人们往往将单独的持续集成或者配置管理实践当成DevOps实践，这就像盲人摸象，每个人都将触摸到的一部分当成大象的整体，如图1-4所示。
图1-4
但是，DevOps涉及的不仅是开发和运营团队。在现有文化的发展中，涉及测试团队、业务分析人员、构建工程师、自动化团队、云团队和许多其他利益相关方。
DevOps和组织文化没有太大区别，它们有共同的价值和行为特征，需要调整心态和过程，与新的技术和工具相匹配。
正因为现实中的一些挑战，使DevOps呈向上的趋势，并成为所有信息技术相关讨论中的热门话题。
开发人员渴望采用新技术和新方法解决问题。但是，他们面对许多挑战。
竞争激烈的市场造成了按时交付的压力。
他们不得不负责生产就绪代码管理和新功能的实现。
发行周期往往很长，因此，开发团队必须在应用部署最终进行之前做出假设。在这种情况下，修复在模拟环境或者生产环境中部署期间发生的问题需要花费更多的时间。
运营团队对资源变化、新技术或新方法的使用总是小心翼翼，因为他们需要稳定性。但是，他们也面对许多挑战。
资源争用：难以处理日益增长的资源需求。
重新设计或者调整：这是在生产环境中运行应用程序的需要。
诊断和改正：他们应该在应用程序部署与外界隔绝的情况下诊断和改正问题。
IT团队向各个团队提供运营所需的资源。
基础设施配给：提供基础设施和具备合适安装软件包的运行时环境。
配置管理：根据工具或者技术的可供更新，升级现有基础设施或者软件包。
考虑到开发和运营团队面对的所有挑战，我们应该如何改善现有过程、利用自动化工具提高过程的效率、改变人们的思维方式？在下一小节，我们将了解如何在组织中发展DevOps文化，改善效率和效能。
低效的估算、进入市场的时间过长以及其他问题导致了瀑布模型的改变，产生了敏捷模型。文化的演变不是有固定时限或者一夜之间可以完成的过程，它可能是一个步进式的分阶段过程，可以在不依赖其他阶段的情况下完成。
我们可以在不使用云配给的情况下实现持续集成，可以在不实现配置管理的情况下实现云配给。我们也可以在没有任何DevOps实践的情况下实现持续测试。图1-5所示是实现DevOps实践的不同阶段。
图1-5
敏捷开发或基于敏捷的方法论对应用程序构建很有用，这种方法将权力下放，鼓励互动，重视可工作软件、客户协作——利用反馈改善后续步骤——并以高效的方式响应变化。
敏捷开发最吸引人的好处之一是在短时间内（敏捷术语中叫作“冲刺”）持续交付。这样，应用开发的敏捷方法、技术上的改进、破坏性创新和方法在开发和运营团队之间造成了一条鸿沟。
DevOps试图通过发展开发和运营团队之间的伙伴关系，弥合这条鸿沟。DevOps活动强调软件开发人员和IT运营部门之间的沟通、协作和整合。
DevOps促进协作，通过自动化和编排改善过程为协作提供方便。换言之，DevOps本质上将敏捷活动的持续开发目标扩展到持续集成和发行。DevOps是利用云解决方案的优势，将敏捷实践与过程组合起来。敏捷开发和测试方法帮助我们实现应用程序的持续集成、开发、构建、部署、测试和发行目标。
自动化构建运用Gradle、Apache Ant和Apache Maven等构建自动化工具，帮助我们创建应用程序构建。
自动化构建过程包括将源代码编译成类文件或者二进制文件、提供第三方库文件引用、提供配置文件路径、将类文件或者二进制文件打包成包文件、执行自动化测试用例、在本地或远程机器上部署包文件和减少包文件创建中的手工作业等活动。
简言之，持续集成（CI）是一种软件工程实践，在这种方法中，开发人员的每次签入（Check-in）都使用如下任一种方法验证。
“拉”机制：在计划的时间点执行自动化构建。
“推”机制：在存储库中保存更改时执行自动化构建。
这一步之后，对源代码库中最新的更改执行一次单元测试。持续集成是一种流行的DevOps方法，要求开发人员将代码每天数次整合为Git和SVN等代码库，以验证代码的完整性。
然后，自动化构建验证每次签入，使团队可以及早发现问题。
CI（甚至CD）是公司同步DevOps存档的基线。在组织中如果没有很好地实施CI和CD，就无法实施DevOps。
在本章前面，我们已经介绍了云计算的基本知识。云配给为架构即代码（Infrastructure as Code ，IAC）敞开了大门，使整个过程变得极其高效，因为我们在很大的程度上将涉及人工干预的过程自动化了。
现收现付的计费模式使所需的资源更加容易承受，不仅对大型组织，对中小规模组织和个人也是如此。
云配给有助于改进和创新，因为以前的资源约束从成本和维护的角度阻碍了组织的进一步发展。一旦我们在基础设施资源上拥有了敏捷性，就可以考虑自动化运行应用程序所需软件包的安装和配置。
配置管理（CM）系统中的更改，更具体地说，就是服务器运行时环境。我们可以使用市场上的许多工具实现配置管理。流行工具包括Chef、Puppet、Ansible、Salt等。
让我们来考虑一个需要管理多个同类配置服务器的例子。
例如，我们需要在每个服务器上安装Tomcat。如果需要改变所有服务器上的端口、更新某些软件包或者为某些用户提供权限，该怎么办？这种情形下的任何修改都是人工的，也就是一种容易出错的过程。因为所有服务器都使用相同的配置，可以利用自动化手段。
持续交付和持续部署是可以互换使用的术语。但是，两者之间还是有一些小的差别。
持续交付是在任何环境中以自动化方式部署一个应用程序并提供持续反馈以改善其质量的过程。持续交付和持续部署中的自动化方法不会改变。但是批准过程和其他小细节可能改变。
持续测试是端到端应用程序生命期管理过程中很重要的阶段，包括功能测试、性能测试、安全性测试等。
Selenium、Appium、Apache JMeter和许多其他工具都可以用于相同的目的。另一方面，持续部署是部署应用程序，包含对生产环境的最新更改。
持续监控是端到端交付流水线的骨干，开源监控工具就像冰淇淋勺的头部。
如图1-6所示，在几乎每个阶段都设置监控，获得所有过程的透明度是十分可取的做法。这还能够帮助我们快速检修故障。监控应该在深思熟虑的计划下执行。
图1-6描述了持续方法的全部过程。
我们必须理解，这是一种分阶段的方法，不一定要一次性完成各个阶段的自动化工作。每次选择一种DevOps实践、实施并理解其好处，然后再实施另一个，这是更有效的做法。
这样，我们可以安全地评估组织文化改变带来的改善，消除应用程序生命期管理中的手工劳动。
图1-6
PPT在任何组织中都是一个重要的词。等等！我们说的可不是PowerPoint演示。这里，我们关注的是人、过程和工具/技术。让我们来了解一下，为什么这些因素在改变任何组织的文化时很重要。
引用Jack Cranfield的名言：
不管周围发生什么，成功的人总是积极地看待人生。他们着眼于过去的成功而不是过去的失败，聚焦于使他们更接近目标的下一步行动，而不是生活中令他们分心的其他事务。
为什么说人很重要？这是一个有趣的问题。如果我们想要用一句话来回答，那就是：因为我们试图改变文化。
那么又如何？
人是任何文化的重要组成部分，只有人能够驱动文化的改变，或者改变自己以适应新过程、定义新过程、学习新工具或者技术。
让我们用变革方程式来理解。
按照维基百科的说法，David Gleicher在20世纪60年代初创造了变革方程式。Kathie Dannemiller在1980年对方程式进行了完善。这个方程式提供了一个模型，以评估影响组织变革倡议成功概率的相对优势。
Gleicher（原始）版本为：C = (ABD) > X，其中C=变革，A=对现状的不满意度，B=希望得到的明确状态，D=达到理想状态的实际步骤，X=变革的代价。
Dannemiller的版本：D×V×F > R，其中D、V和F必须存在，组织变革才能进行：D=对现状的不满意度，V=对可能目标的愿景，F=可用于实现愿景的前几个具体步骤。如果这3个因素的乘积大于R（阻力），那么变革就是可能成功的。
本质上说，这个公式表示，必须有对现有事务或者过程的不满，对新趋势、技术和市场方案创新的愿景，以及实现愿景所采取的具体步骤。
关于变革方程式的更多细节，可以访问维基百科网页：https://en.wikipedia.org/wiki/Formula_for_change#cite_note-myth-1。
作为经验分享，我认为培训人员适应新的文化非常重要，这是一场需要耐心的博弈。我们不能在一夜之间改变人们的思维方式，在改变文化之前首先需要理解。
在行业中往往能看到，文化的改变从DevOps知识或者DevOps工程师开始，但是在理想状况下，这些不应该是“舶来品”，而应该逐步改变现有环境，并在其中训练人员，以控制阻力。我们不需要一个专门的DevOps团队，需要的是开发人员、测试团队、自动化实现人员和云或基础设施团队之间的更多沟通和协作。
让所有人都理解彼此的痛点是必不可少的步骤。在我工作过的机构里，我们习惯于有一个卓越中心（COE）来管理新技术、创新或者文化。作为自动化实现者和DevOps团队的一员，我们只应该担当促进者的角色，而不是与世隔绝的“竖井”中的一员。
Tom Peters曾有一段名言：
几乎所有质量改进都来源于对设计、制造…布局、过程和规程的简化。
在处理文化的发展时，质量极其重要。我们需要过程和策略，以正确的方式完成工作，并标准化各个项目，使操作的顺序、约束、规则等都有完备的定义，以便对成功与否进行度量。
我们需要为以下任务建立过程。
敏捷规划。
资源规划和配给。
配置管理。
对云资源和自动化中使用的其他工具的基于角色访问控制。
编程语言的静态代码分析规则。
测试方法论与工具。
发行管理。
这些过程对于度量DevOps文化发展的成功也很重要。
史蒂夫•乔布斯有如下的名言：
技术并不重要，重要的是你对人们有信心，他们都很好、很聪明，如果给他们工具，他们就能做了不起的事。
科技帮助人和组织产生创意、完成创新，同时改变文化。没有科技，在日常例行的自动化操作中，就很难实现速度和效率。云计算、配置管理工具和构建流水线在资源配给、安装运行时环境和编排中很有用处。它们从根本上提高了应用程序生命期管理中不同方面工作的速度。
是的，工具什么都不是，在任何组织的文化变革中，它们都不是重要的因素。原因很简单。不管我们使用哪一种技术，都必须实施持续集成、云配给、配置管理、持续交付、持续部署、持续监控等。
按照类别，可以使用不同的工具集，但是所有工具执行的都是类似的操作。工具执行某个操作的方式可能不同，但结果是相同的。表1-1所示是按照分类列出的一些工具。
表1-1
| 分类 |
工具 |
|---|---|
| 构建自动化 |
Nant、MSBuild、 Maven、 Ant和Gradle |
| 存储库 |
Git和SVN |
| 静态代码分析 |
Sonar和PMD |
| 持续集成 |
Jenkins、 Atlassian Bamboo和VSTS |
| 配置管理 |
Chef、 Puppet、 Ansible和Salt |
| 云平台 |
AWS 和Microsoft Azure |
| 云管理工具 |
RightScale |
| 应用程序部署 |
Shell Scripts和Plugins |
| 功能测试 |
Selenium和Appium |
| 负载测试 |
Apache Jmeter |
| 构件仓库 |
Artifactory、 Nexus和 Fabric |
让我们来看看在不同运营工作的不同阶段使用的不同工具。这可能根据不同组织中的环境数量或者DevOps实践数量而变化，如图1-7所示。
图1-7
如果我们需要根据不同的DevOps最佳实践分类工具，可以将其分类为开源和商业。表1-2所示为一些例子。
表1-2
| 组件 |
开源 |
IBM Urban Code |
Electric-Cloud |
|---|---|---|---|
| 构建工具 |
Ant 或Maven或 MS Build |
Ant或Maven 或 MS Build |
Ant或Maven或MS Build |
| 代码库 |
Git或Subversion |
Git或Atlassian Stash 或 Subversion 或 StarTeam |
Git 或 Subversion 或 StarTeam |
| 代码分析工具 |
Sonar |
Sonar |
Sonar |
| 持续集成 |
Jenkins |
Jenkins 或Atlassian Bamboo |
Jenkins 或 ElectricAccelerator |
| 持续交付 |
Chef |
Artifactory 和IBM UrbanCode |
Deploy ElectricFlow |
在本书中，我们将聚焦于开源和商业工具。我们将在所有重要的自动化和编排相关活动中使用Jenkins和Visual Studio Team Services。
DevOps是一种文化，我们对此已经很了解。但是，在实施自动化、制定过程和发展文化之前，我们必须理解组织文化的现状，以及是否有必要引入新过程或者自动化工具。
我们必须非常清楚，我们需要的是使现有文化变得更加高效，而不是输入文化。在本书的篇幅中可能很难容纳一整个评估框架，但是我们将尽力提供一些问题和提示，并以此为基础，创建一个评估框架就会更容易。
创建需要提出的问题类别，并根据具体应用得出答案。
下面是几个问题的例子。
1．你是否遵循敏捷原则？
2．你是否使用源代码库？
3．你是否使用静态代码分析工具？
4．你是否使用构建自动化工具？
5．你使用场内基础设施还是基于云的基础设施？
6．你使用配置管理工具、安装应用程序软件包的脚本还是运行时环境？
7．你是否使用自动化脚本在生产和非生产环境中部署应用程序？
8．你是否使用应用程序生命期管理的编排工具或者脚本？
9．你是否使用功能测试、负载测试、安全性测试和移动测试的自动化工具?
10．你是否使用应用程序和基础设施监控工具？
一旦问题就绪，就准备答案，并根据上述问题的每个答案确定等级。
保证框架的灵活性，即使我们改变任何类别中的一个问题，也能够自动地管理。
评出等级之后，在框架中引入不同的条件和智能，捕捉答案并计算总体等级。
创建各个分类的最终等级，根据最终等级创建不同类型的图表，使其更容易理解。在这里，需要注意的是，组织在应用程序生命期管理各领域中的专业能力。这将为评估框架提供一个新的维度，以增加智能，使其更为高效。
在本章中，我们设定了本书要实现的许多目标。我们介绍了持续集成、云环境中的资源配给、配置管理、持续交付、持续部署和持续监控。
设计目标是将愿景清晰化的第一步。
——Tony Robbins
我们已经看到，云计算是如何改变过去对创新的认知方法，它现在已经变成了切实可行的方案。我们还简要介绍了DevOps的必要性和各种不同的DevOps实践。人、过程和技术在改变组织现有文化的过程中也很重要。我们试图指出它们的重要性。工具很重要，但不能止步于此；可以利用任何工具集，改变文化并不需要特定的工具集。我们也简要地讨论了DevOps的评估框架，它将帮助你沿着文化变革的道路前进。
信念，就是在你还没有看到整个楼梯的时候走出第一步。
——马丁•路德•金
在下一章中，我们将迈出本次旅程的第一步——持续集成。我们将使用Jenkins和Microsoft Visual Studio Team Services实施持续集成，验证如何用不同的工具实施CI，而又无须面临重大的挑战。
